Opened 18 years ago
Closed 18 years ago
#946 closed defect (invalid)
MySQL server gone away bug with MySQL 4.1 and 5.0
Reported by: | 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)
Change History (8)
Changed 18 years ago by
Attachment: | mythbackend.log.bz2 added |
---|
comment:2 Changed 18 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
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 18 years ago by
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
This is not a message board.
comment:4 Changed 18 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Version: | 0.18.1 → head |
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 18 years ago by
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
This is not a chat room.
comment:6 Changed 18 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
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 18 years ago by
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
mythtv-users . This is not a bulletin board and public access will need to be shut off if it is used as such.
error log