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.
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)
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?
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 🙂
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 🙂
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
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