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.

Share this post

Comments (9)

  • shane bester

    I filed a bug report about the ‘repair table’ getting mapped to ‘recreate + analyze’:
    (map ‘repair table’ to recreate +analyze for engines not supporting native repair)

    May 15, 2010 at 6:37 am
  • rich

    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?

    May 15, 2010 at 7:56 am
  • peter


    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 🙂

    May 15, 2010 at 7:33 pm
  • Yvan

    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 🙂

    May 16, 2010 at 1:52 am
  • Manish


    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
    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 OK
    mysql.ndb_binlog_index OK
    mysql.plugin OK
    mysql.proc OK
    mysql.procs_priv OK
    mysql.servers OK
    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’…

    October 29, 2012 at 6:09 am
  • Kubilay

    Peter thank you for this nice post!

    I checked mysql bug list see bug reported here:

    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!


    January 2, 2014 at 8:05 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.