Opened 14 years ago

Closed 13 years ago

#946 closed defect (invalid)

MySQL server gone away bug with MySQL 4.1 and 5.0

Reported by: d.r.newman@… Owned by: Isaac Richards
Priority: major Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords: MySQL server connection
Cc: Ticket locked: no

Description

Ever since I changed to MySQL 4.1 and then MySQL 5.0, mythtv has been falling over 2 or 3 times a week. Mythbackend looses its connection to MySQL, and keeps attempting to kick the database into life. I get lots of errors like the extract I have pasted below. I have not detected a consistent pattern causing the loss of MySQL connection, although I have noticed it happens if mythtv does not do any recording for a day, and when I am quickly browsing through the menus.

In the source code, there are several references to code written to get around bugs in the way MySQL3 behaves. Perhaps the MySQL oddities have been fixed in the more recent version, so the work-arounds no longer work.

I don't understand the code well enough to fix it myself, but I am happy to test code sent to me by others.

One possible fix would be to give up persistent connections for good, and just open a new connection every time mythbackend wants to connect to the database. After all, mythbackend doesn't hit the database all that much, compared to your typical CMS on a web server.

 --<part of mythbackend.log>--
 2006-01-05 08:23:31.245 Started recording "Will and Grace" on channel: 4 on cardid: 1, sourceid 1
 DB Error (KickDatabase):
 Query was:
 SELECT NULL;
 Driver error was [2/2006]:
 QMYSQL3: Unable to execute query
 Database error was:
 MySQL server has gone away

 2006-01-05 08:23:31.249 scheduler: Schedule Change
 DB Error (KickDatabase):
 Query was:
 SELECT NULL;
 Driver error was [2/2006]:
 QMYSQL3: Unable to execute query
 Database error was:
 MySQL server has gone away

 DB Error (KickDatabase):
 Query was:
 SELECT NULL;
 Driver error was [2/2006]:
 QMYSQL3: Unable to execute query
 Database error was:
 MySQL server has gone away

Attachments (1)

mythbackend.log.bz2 (128.3 KB) - added by d.r.newman@… 14 years ago.
error log

Download all attachments as: .zip

Change History (8)

Changed 14 years ago by d.r.newman@…

Attachment: mythbackend.log.bz2 added

error log

comment:1 Changed 14 years ago by Isaac Richards

Resolution: wontfix
Status: newclosed

Not a mythtv bug.

comment:2 Changed 13 years ago by anonymous

Resolution: wontfix
Status: closedreopened

Hmm...

I see this problem also. Could you explain why you don't see this as a mythtv bug that when a DB connection is dropped (e.g. for being idle too long) that mythtv doesn't successfully reconnect & needs restarting.

Especially since there appears to be no way to tune the idle timeout for mysql that I can find... In fact the only place it seems to be mentioned on the mysql website is recommending that either the app reconnects successfully, or occaisonally pings the connection... Personally I see the reconnect being more mandatory as there are lots of things that can drop the connection. e.g. DB server reboot, firewall stte tables timeout etc.

comment:3 Changed 13 years ago by Isaac Richards

Resolution: wontfix
Status: reopenedclosed

This is not a message board.

comment:4 Changed 13 years ago by Elan Ruusamäe <glen@…>

Resolution: wontfix
Status: closedreopened
Version: 0.18.1head

i'm encountering the same problem, that after some time connections die, and when last one of them gets dropped, no recordings are being made and they're even not visible via frontend.

i'm using mysql 5.0.16+ mysql server and mythtv is from svn (had the problem since 0.18.1 version and with current r8763)

my interactive_timeout and wait_timeout are 8hours (28800).

please don't mark this issue as WONTFIX, as i think this is critical if no recordings are made due inability to reconnect to database.

comment:5 Changed 13 years ago by Isaac Richards

Resolution: invalid
Status: reopenedclosed

This is not a chat room.

comment:6 Changed 13 years ago by anonymous

Resolution: invalid
Status: closedreopened

If this isn't the place to discuss the particulars of this bug, it would be helpful if you would tell us where we should be doing it. It sure appears to be the right place.

Additionally, it would be helpful to hear your opinion on why making myth's connection to the database more robust and resilient is a bad thing.

Just about the only thing that would be patently unhelpful to myth and its users would be for you to close this bug again with a dismissive one-liner.

comment:7 Changed 13 years ago by bjm

Resolution: invalid
Status: reopenedclosed

mythtv-users . This is not a bulletin board and public access will need to be shut off if it is used as such.

Note: See TracTickets for help on using tickets.