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
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