[mythtv] mysql 5 bug affecting mythtv

Keith Pyle kpyle at austin.rr.com
Sun Jan 27 18:19:23 UTC 2008


Thanks for the comments.  Here's a consolidated reply.
> Rob Smith wrote:
> Can you drop all the indexes on credits and see if you still have the
> same problem? If not, re-add them and see?
>   
I will give this a try and report back in a week or so.  Thanks for the 
suggestion.
> David Backenberg wrote:
> I, along with probably a lot of other people on this list, are running
> MySQL 5 with Myth without incident.
>
> Out of curiousity, are you using MyISAM or InnoDB as the engine for
> your myth tables?
>   
> I had problems with MyISAM tables getting corrupted, which I would
> later fix with myisamchk.
> Since ALTER-ing all my myth tables to InnoDB
>
> 1) I haven't had the corruption problems
> 2) Database intensive operations, like scrolling the program guide as
> fast as the keyboard will let me are dramatically faster
>   
> Chances are your bug hasn't been fixed because people have had trouble
> reproducing it, therefore it might not be a problem with MySQL, but
> rather your particular tables running inside MySQL.
>   
The tables are all MyISAM.  Changing to InnoDB is worth considering.  If 
dropping the index and recreating it for the credits table as suggested 
by Rob does not work, I'll switch the tables to InnoDB.

I have seen no evidence of corruption, except when mysqld crashes.  I 
regularly run "mysqlcheck --check -A -e" with no problems found.

I agree that it is likely hard to reproduce and therefore not getting 
much attention.  However, I disagree that it is not a problem inside 
MySQL.  If a service crashes with a segmentation violation, it has a bug 
and the code should be doing better data validation.  That said, I'm not 
expecting a quick (or perhaps any) fix from mysql.
> Michael T. Dean wrote:
>
> OP, did you upgrade MySQL using
> http://mythtv.org/docs/mythtv-HOWTO-23.html#ss23.5 (recommended
> approach) or by just copying (leaving?) the binary database files into
> place?  I've seen binary-file-upgrades corrupt the DB (possibly index or
> whatever).
>   
No, it was not a binary upgrade.  The upgrade process was taken from the 
mysql site documentation:
- backup the database with mysqldump
- save the contents of /etc/mysql
- rename /var/lib/mysql to move the database directory out of the way 
(and preserve it if the upgrade failed)
- create a new, empty database directory
- install the new mysql version
- build the skeleton DB with mysql_install_db
- start the new mysqld version
- load the database from the backup created with mysqldump
- upgrade the grant tables with mysql_upgrade
- stop and restart the mysql daemon
- verify the tables with mysqlcheck



More information about the mythtv-dev mailing list