I forgot to file this one a hundred times, here it finally is: When upgrading from MySQL 4.1 to 5.0, there is one caveat: The seamless upgrade does NOT work for Merge Tables [which is basically a concatenation of seperate tables into one virtual table]. I noticed that when upgrading my phpsyslog-ng installation (ref: bug #151021). Once you re-create the Merge Table you will start to get strange error messages saying that your MyISAM tables are not identical. As far as I found out, the MyISAM tables MySQL 5 uses do have a higher version number than the old ones. The problem really only occurs with Merge Tables. There is a bug about that somewhere at MySQL, but I lost the reference in the process of constatnly forgetting to file this bug :P After a long speach, my recommendation is to put something in the guide that tells users of Merge Tables to dump and restore those during the process (or just use the 4.0 -> 4.1 process, after all). Regards, Wolf
(In reply to comment #0) > I forgot to file this one a hundred times, here it finally is: > > When upgrading from MySQL 4.1 to 5.0, there is one caveat: The seamless upgrade > does NOT work for Merge Tables [which is basically a concatenation of seperate > tables into one virtual table]. > > I noticed that when upgrading my phpsyslog-ng installation (ref: bug #151021). > > Once you re-create the Merge Table you will start to get strange error messages > saying that your MyISAM tables are not identical. As far as I found out, the > MyISAM tables MySQL 5 uses do have a higher version number than the old ones. > The problem really only occurs with Merge Tables. > > There is a bug about that somewhere at MySQL, but I lost the reference in the > process of constatnly forgetting to file this bug :P > > After a long speach, my recommendation is to put something in the guide that > tells users of Merge Tables to dump and restore those during the process (or > just use the 4.0 -> 4.1 process, after all). Can you please give us some specific code samples and accompanying text, as well as where exactly it should be? Doesn't have to be a guidexml patch or anything; we just need something to go on. :)
At least I found another reference for the problem, look at "Posted by Johannes Ullrich on October 31 2006 1:55pm" on this page: http://dev.mysql.com/doc/refman/5.0/en/merge-table-problems.html So, I think you should extend the introduction under 1. to something like this: The myisam storage engine in version 4.1 was already mature enough to allow a direct upgrade to the next major version of MySQL. Nothe that this is not true for MERGE Tables. You will likely run into trouble if you attempt a direct upgrade for this (rarely used) type of table. Be advised that you should dump and recreate those tables and restore their contents in the process of upgrading. If unsure, follow method 2. "Uppgrading from old versions of MySQL". I think that'd be sufficient, since I doubt a lot of people are using that feature (except for the MASSES of phpsyslog-ng users, of course ^_^) Feel free to ask if you need anything else. [Ref: http://www.gentoo.org/doc/en/mysql-upgrading.xml]
(In reply to comment #2) > [. . .] Okay, so no actual code samples are necessary? Just the warning about if unsure, proceed to 2? Works for me. Will do.
Should work (note I can't swear it does, since I ran into the problem and fixed it _afterwards_), but for testing purposes I just ran mysqldump on the MERGE table a few seconds ago and it produces everything necessary to recreate it, so I can't see anything at all contradicting my expectation that using the "standard procedure" (under "2.") will work.
Added your suggestion as-is to the guide. Thank you very much for reporting. Fixed in CVS.
