Gnucash in "MySQL server has gone away" loop
John Ralls
jralls at ceridwen.us
Mon Oct 3 22:29:27 EDT 2011
On Oct 3, 2011, at 6:21 PM, Christopher X. Candreva wrote:
> On Mon, 3 Oct 2011, John Ralls wrote:
>
>>
>> On Oct 1, 2011, at 8:39 PM, Christopher X. Candreva wrote:
>>
>>>>> I'm not that familiar with MySql, but it sounds like the database has
>>>>> problems. Can you connect to it with the mysql client program? Does
>>>>> mysqlcheck report any errors? Are the permissions correct?
>>>
>>> I've connected both with the mysql command line and phpMyAdmin, and dumped
>>> the database with mysqldump, so I'm sure the user can access it. Moreover,
>>> I've been writing to the same database for over a month. It's not dieing on
>>> the initial connect, it does quite a bit of work before it goes into the
>>> reconnect loop.
>>>
>>> This same server runs my Mythtv backend, which makes heavy use of the mysql
>>> server and is not having any problems. (I shutdown mythv while testing so I
>>> know it's not putting a load that is causing the problem)
>>>
>>> Recapping, saving to SQL from a month old XML file will work. I'm guessing
>>> it's either some data I entered last time, or something about the size I've
>>> reached.
>>>
>>> I've placed both the gnucash.trace and mysql transaction log files at
>>> http://www.westnet.com/~chris/gnucash/ If this helps. They are from the same
>>> run, so the time stamps should match. You can see in the mysql log that 55
>>> querys are performed successfully before it enters the reconnect loop. The
>>> trace ends with me hitting Ctrl-C
>>>
>>
>> So it looks like a couple of queries are hanging up. There may be two separate issues here:
>> * Either the splits or slots table (I'd vote for slots, just because it tends to be problematic) is corrupted somehow so that the
>> queries to retrieve them time out.
>>
>> * When a query times out, Gnucash goes into a reconnect loop and
>> effectively hangs. I'll have a look at that code and try to figure out
>> what's going on.
>>
>> Do I understand correctly that you did a mysqldump of the current database
>> and successfully (meaning that you were able to open it from Gnucash)
>> restored it on your client machine? If that's the case, perhaps restoring
>> it onto your server will get you going again.
>
> Yes you undserstand correctly. I just tried restoring the dump to the
> server's (F15) server and still ran into the reconnect loop. What I had
> tried previously was to drop all tables on the server and use Gnucash to
> load from the client's Mysql and save TO the server's SQL. I had the same
> reconnect loop when I tried to read this back from the server's mysql.
>
> The database passed mysqlcheck without errors
Interesting. I'm running out of ideas here.
When the db loads successfully from your F14 box, how long do those two queries -- the slots and splits ones that are the last two logged in the mysql log -- take to complete? It would show in the gnucash tracefile as a time lag between ending the Transasction loading and beginning to load whichever of the two starts first.
Regards,
John Ralls
More information about the gnucash-user
mailing list