Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Buldbot tests upgrade and upgrade2 attempt to do the live upgrade from 5.1.49 to the current version. It does not work for 10.0 anymore (and for MySQL 5.1 => 5.6 too). Upgrade 5.1 => 5.5 works, 5.5 => 5.6 / 10.0 works, but the direct upgrade 5.1 => 5.6 does not, it complains about InnoDB auto-extending:
2013-08-08 18:47:25 8805 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 640 pages (rounded down to MB) than specified in the .cnf file: initial 768 p
|
ages, max 0 (relevant if non-zero) pages!
|
2013-08-08 18:47:25 8805 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you sh
|
ould now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of
|
zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!
|
2013-08-08 18:47:25 8805 [ERROR] Plugin 'InnoDB' init function returned error.
|
2013-08-08 18:47:25 8805 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
|
(The messages above are from MySQL 5.1 => 5.6 upgrade).
Since it's a general recommendation to go through releases consequently, it's probably not a code bug, and we need to change the test for 10.0 to do the upgrade from 5.5, if possible.
Examples of the failures:
http://buildbot.askmonty.org/buildbot/builders/kvm-deb-debian6-x86/builds/2171
(upgrade, upgrade2)
Attachments
Issue Links
- relates to
-
MDEV-4786 merge 10.0-monty → 10.0
-
- Closed
-
Activity
In general it seems to be reasonable, but it's always scary to touch VMs before the release. Besides, if a distribution still has 5.1 by default, it does make sense to test the upgrade from it.
I'm going to try to fix it differently, got the ideas from IRC:
- either by creating and populating an InnoDB table, so that the datafile grows above the new default, and the issue with auto-extending becomes irrelevant;
- or by adding the old option value ibdata1:10M:autoextend to the cnf file.
The first solution makes much more sense, I'm trying it now – modified the 'upgrade' test, if it works, I will do the same for upgrade2.
It worked for upgrade, added now for upgrade2 too. Once it passes, I will close the task, and we can decide about replacing 5.1 with 5.5 later.
Works now:
http://buildbot.askmonty.org/buildbot/builders/kvm-deb-debian6-x86/builds/2793
In 'upgrade' test: create a new innodb table and insert several thousand rows into it, so that the default table space grows above both old and new start values;
in 'upgrade2' test: additionally set innodb_file_per_table = 0 because it might be set differently in MariaDB. To avoid errors in case there is no innodb_file_per_table, MySQL client for this set of commands is run with --force.
Since we're not really releasing 5.1-5.3 packages very often these days would it make sense to install MySQL 5.5 on all of the 5.5 upgrade VMs and MariaDB 5.5 on all of the upgrade2 VMs?
Many of the recent VMs are this way already, but older upgrade/upgrade2 VMs have 5.1.