In section 3.5 of the upgrade documentation, the procedure is given to import the previously saved data back into MySQL. Depending upon table order and InnoDB foreign key dependencies, the import will fail to create tables that are dependent upon tables that are created later in the dump. The errors regarding table creation are not necessarily obvious. You might want to mention the resolution in the document. This can be resolved by inserting the following line into the backup file: SET FOREIGN_KEY_CHECKS=0 And then re-enabling the checks at the end of the file: SET FOREIGN_KEY_CHECKS=1 Also note that issuing SET AUTOCOMMIT=0 and SET SQL_LOG_BIN=0 might increase the speed of the upload for large sets of data.
yes, this should be noted as foreign key support is somewhat new, and I honestly wouldn't be surprised that sql imports would cause this.
*** Bug 120853 has been marked as a duplicate of this bug. ***
(In reply to comment #0) Uh, is this still an issue? The original report is a year old; mysql versions have come and gone. CCing chriswhite, as he's the master of all things mysql. What do you think, chris? Should we add any of the suggestions here to the guide?
Created attachment 105643 [details] http://overlays.gentoo.org/proj/mysql/changeset/508?format=diff&new=508 Mentioning the problem should be enough these days
Created attachment 105647 [details] http://overlays.gentoo.org/proj/mysql/changeset/509?format=diff&new=509 Another change that fix a real bug in the flow of the unload, LOCKs are bound to sessions, so execute "FLUSH TABLES WITH READ LOCK" the way it's now is a totally non-sense. Thanks to Alex Efros that mentioning it in gentoo-server ml.
Fixed in CVS, thanks for reporting and to vivo for the patches.
