July 22, 2014

mysql_upgrade and Innodb Tables

Upgrading from MySQL 5.0 to MySQL 5.1 or Percona Server 5.1 you may run into issues with mysql_upgrade – it will identify some tables to be upgraded and will attempt to run REPAIR TABLE for them. This will fail with “The storage engine for the table doesn’t support repair” error message. This seems to confuse a lot of people and I’ve seen people doing failsafe upgrade path of dumping and reloading complete database confused by this error message, which of course works, but can take quite a lot of time.

Another solution is to simply run ALTER TABLE tbl ENGINE=INNODB which will rebuild table with new MySQL version and normally will fix issues identified by mysql_upgrade.
You can use mysqlcheck -A –check-upgrade to identify tables which need to be fixed such a way.

With Oracle intentions to make Innodb default storage engine in next MySQL release I’m hopeful minor annoyances like this will be fixed. It should not be that complicated to at least map REPAIR TABLE to null ALTER TABLE which will help with most issues.

There is nice bug filed about it though it only covers documentation aspects.

About Peter Zaitsev

Peter managed the High Performance Group within MySQL until 2006, when he founded Percona. Peter has a Master's Degree in Computer Science and is an expert in database kernels, computer hardware, and application scaling.

Comments

  1. I filed a bug report about the ‘repair table’ getting mapped to ‘recreate + analyze’:

    http://bugs.mysql.com/bug.php?id=47205
    (map ‘repair table’ to recreate +analyze for engines not supporting native repair)

  2. rich says:

    What are the consequences of NOT doing this. That is, suppose you upgrade mysql from 5.0.x to 5.1.y and leave many tables in the state where mysql reports that these tables need to be repaired. Mysql still seems to function even on these tables. Is it slower? What happens?

  3. peter says:

    Rich,

    I trust this depends on the exact nature of changes. Most typically the changes came from the sort order changes in newer versions which would mean indexes would contain data in the wrong order which can cause some glitches down the road – for example different result from query depending on if index was used. In most cases behavior is changed in the edge cases so you may see no difference at all. In practice there are many people running MySQL 5.1 as drop in replacement for MySQL 5.0 not even bothered to run mysql_upgrade :)

  4. Yvan says:

    Thanks a lot Peter, I’ve just upgraded to 5.1, to use RBR, and every day the slave was hanging on «Could not execute Update_rows event on table t1; Can’t find record in ‘t1′, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND».

    The table was a MEMORY one, and by doing your check command, I’ve found that the master’s table was to be repaired (it’s not possible as it’s a MEMORY table, but your ALTER command did it fine!). So I think that was one of the issues.

    And I just understood that if I replicate the MEMORY table using RBR, and restart one server, the data in-memory will be purged, and the slave won’t be able to replicate all instructions, hence, it will hang again. So I should force SBR for MEMORY tables (or not use any MEMORY table :-)

  5. Manish says:

    Hi,

    This is the first time I have used the mysql_upgrade command, and it seems to be checking only the tables inside ‘mysql’ DB.

    I’m not sure if that’s normal, coz it should be checking all the tables in all the DBs and not just the tables inside ‘mysql’ DB.

    Here is the result of wat happens when i give the command:-

    C:\Users\user>mysql_upgrade –force –verbose -uroot -proot
    Looking for ‘mysql.exe’ as: C:\Program Files\MySQL\MySQL Server 5.1\bin\mysql.exe
    Looking for ‘mysqlcheck.exe’ as: C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqlcheck.exe
    Running ‘mysqlcheck’ with connection arguments: “–port=3306″
    Running ‘mysqlcheck’ with connection arguments: “–port=3306″
    mysql.columns_priv OK
    mysql.db OK
    mysql.event OK
    mysql.func OK
    mysql.general_log
    Error : You can’t use locks with log tables.
    status : OK
    mysql.help_category OK
    mysql.help_keyword OK
    mysql.help_relation OK
    mysql.help_topic OK
    mysql.host OK
    mysql.ndb_binlog_index OK
    mysql.plugin OK
    mysql.proc OK
    mysql.procs_priv OK
    mysql.servers OK
    mysql.slow_log
    Error : You can’t use locks with log tables.
    status : OK
    mysql.tables_priv OK
    mysql.time_zone OK
    mysql.time_zone_leap_second OK
    mysql.time_zone_name OK
    mysql.time_zone_transition OK
    mysql.time_zone_transition_type OK
    mysql.user OK
    Running ‘mysql_fix_privilege_tables’…
    OK

  6. Kubilay says:

    Peter thank you for this nice post!

    I checked mysql bug list see bug reported here: http://bugs.mysql.com/bug.php?id=44640

    The thing is that in 5.1 the banner of MySQL is changing as well, now is an ‘Oracle’ product. One should have confidence in the command mysql_upgrade if it gives confusing messages like this and having this recorded as a minor bug is not enough, it leaves the DBA in a ‘limbo’ staten on what to do. Is the upgrade valid? Can the error message be ignored?

    Has anybody heard a workaround from Oracle on this yet.

    Many thanks and all the best!

    Kubilay

Speak Your Mind

*