[Maria-discuss] Upgrade paths through more major versions
Hello, MariaDB changed its release cycle to 1 major version / year. However the upgrades remained supported only from one major version to the very next. I see a raise of users (of RH products - RHEL and RHSCL mainly) that would like to jump several versions. They had an application build on, let's say, 5.5 (RHEL7 default) and would like to get the features from 10.2 (available in RH software collections - we provide plenty of versions this way). So far, they have to upgrade one by one 5.5->10.0->10.1->10.2; and solve the conflicts at each stage. Lately, we discontinued support fo 10.0 in RHSCL, which means, the upgrade path metioned above won't be as easy anymore. Also mysqldump can't be used for upgrade to 10.3, which is IMHO frequently used. For other RH products, there is an ongoing discussions, whether support all major releases or if to skip some. Which implies the questions about the upgrades through versions we wouldn't pack. However skipping several versions is IMHO quite normal for products with slow release cycle, like RHEL, so I'd expect other companies providing similar systems / products with slow release cycle to face the same problems. Are there any plans to extend the upgrade paths through more versions? Have you encountered simmilar needs of the users? -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat
Hi Michal, Le mer. 6 juin 2018 à 12:02, Michal Schorm <mschorm@redhat.com> a écrit :
Hello,
MariaDB changed its release cycle to 1 major version / year. However the upgrades remained supported only from one major version to the very next.
What's the definition of the term "supported" here? I've never seen such a claim elsewhere. Maybe 1 major version to next are "recommended", but even in some upgrades you can find breaking changes.
I see a raise of users (of RH products - RHEL and RHSCL mainly) that would
like to jump several versions. They had an application build on, let's say, 5.5 (RHEL7 default) and would like to get the features from 10.2 (available in RH software collections - we provide plenty of versions this way). So far, they have to upgrade one by one 5.5->10.0->10.1->10.2; and solve the conflicts at each stage.
That's a waste of time. Such an upgrade is perfectly possible through the means of mysqldump and reload. In-place upgrades might cause some issues because of innodb version changes, but for example, from 10.0 to 10.1, they are rarely an issue because the version of InnoDB hasn't changed. The recommended upgrade path from any version is always the same e.g. dump and reload.
Lately, we discontinued support fo 10.0 in RHSCL, which means, the upgrade path metioned above won't be as easy anymore. Also mysqldump can't be used for upgrade to 10.3, which is IMHO frequently used.
Where have you seen that claim? I've imported dumps to 10.3 without particular issues. -- Guillaume Lefranc Signal 18 Consulting
Thanks for the reply, On Wed, Jun 6, 2018 at 2:20 PM, Guillaume Lefranc <guillaume@adishatz.net> wrote:
Also mysqldump can't be used for upgrade to 10.3, which is IMHO frequently used.
Where have you seen that claim? I've imported dumps to 10.3 without particular issues. https://mariadb.com/kb/en/library/upgrading-from-mariadb-102-to-mariadb-103/... -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat On Wed, Jun 6, 2018 at 2:20 PM, Guillaume Lefranc <guillaume@adishatz.net> wrote:
Hi Michal,
Le mer. 6 juin 2018 à 12:02, Michal Schorm <mschorm@redhat.com> a écrit :
Hello,
MariaDB changed its release cycle to 1 major version / year. However the upgrades remained supported only from one major version to the very next.
What's the definition of the term "supported" here? I've never seen such a claim elsewhere. Maybe 1 major version to next are "recommended", but even in some upgrades you can find breaking changes.
I see a raise of users (of RH products - RHEL and RHSCL mainly) that would
like to jump several versions. They had an application build on, let's say, 5.5 (RHEL7 default) and would like to get the features from 10.2 (available in RH software collections - we provide plenty of versions this way). So far, they have to upgrade one by one 5.5->10.0->10.1->10.2; and solve the conflicts at each stage.
That's a waste of time. Such an upgrade is perfectly possible through the means of mysqldump and reload. In-place upgrades might cause some issues because of innodb version changes, but for example, from 10.0 to 10.1, they are rarely an issue because the version of InnoDB hasn't changed. The recommended upgrade path from any version is always the same e.g. dump and reload.
Lately, we discontinued support fo 10.0 in RHSCL, which means, the upgrade path metioned above won't be as easy anymore. Also mysqldump can't be used for upgrade to 10.3, which is IMHO frequently used.
Where have you seen that claim? I've imported dumps to 10.3 without particular issues.
-- Guillaume Lefranc Signal 18 Consulting
Hi Michal, it says the following - mysqldump <https://mariadb.com/kb/en/mysqldump/> in MariaDB 10.3 <https://mariadb.com/kb/en/what-is-mariadb-103/> includes logic to cater for the mysql.transaction_registry table <https://mariadb.com/kb/en/mysqltransaction_registry-table/>. mysqldump from an earlier MariaDB release cannot be used on MariaDB 10.3 <https://mariadb.com/kb/en/what-is-mariadb-103/> and beyond. It means that you cannot use the mysqldump _binary_ from 10.2 and earlier on MariaDB 10.3 version and beyond. That's OK because you don't need mysqldump when restoring your data. And presumably, you won't use an older mysqldump binary to dump your MariaDB 10.3 data, right? Regards GL Le mer. 6 juin 2018 à 14:48, Michal Schorm <mschorm@redhat.com> a écrit :
Thanks for the reply,
On Wed, Jun 6, 2018 at 2:20 PM, Guillaume Lefranc <guillaume@adishatz.net> wrote:
Also mysqldump can't be used for upgrade to 10.3, which is IMHO frequently used.
Where have you seen that claim? I've imported dumps to 10.3 without particular issues.
https://mariadb.com/kb/en/library/upgrading-from-mariadb-102-to-mariadb-103/...
--
Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat
On Wed, Jun 6, 2018 at 2:20 PM, Guillaume Lefranc <guillaume@adishatz.net> wrote:
Hi Michal,
Le mer. 6 juin 2018 à 12:02, Michal Schorm <mschorm@redhat.com> a écrit :
Hello,
MariaDB changed its release cycle to 1 major version / year. However the upgrades remained supported only from one major version to the very next.
What's the definition of the term "supported" here? I've never seen such a claim elsewhere. Maybe 1 major version to next are "recommended", but even in some upgrades you can find breaking changes.
I see a raise of users (of RH products - RHEL and RHSCL mainly) that
would like to jump several versions. They had an application build on, let's say, 5.5 (RHEL7 default) and would like to get the features from 10.2 (available in RH software collections - we provide plenty of versions this way). So far, they have to upgrade one by one 5.5->10.0->10.1->10.2; and solve the conflicts at each stage.
That's a waste of time. Such an upgrade is perfectly possible through the means of mysqldump and reload. In-place upgrades might cause some issues because of innodb version changes, but for example, from 10.0 to 10.1, they are rarely an issue because the version of InnoDB hasn't changed. The recommended upgrade path from any version is always the same e.g. dump and reload.
Lately, we discontinued support fo 10.0 in RHSCL, which means, the upgrade path metioned above won't be as easy anymore. Also mysqldump can't be used for upgrade to 10.3, which is IMHO frequently used.
Where have you seen that claim? I've imported dumps to 10.3 without particular issues.
-- Guillaume Lefranc Signal 18 Consulting
Am 06.06.2018 um 14:20 schrieb Guillaume Lefranc:
That's a waste of time. Such an upgrade is perfectly possible through the means of mysqldump and reload. In-place upgrades might cause some issues because of innodb version changes, but for example, from 10.0 to 10.1, they are rarely an issue because the version of InnoDB hasn't changed. The recommended upgrade path from any version is always the same e.g. dump and reload.
sorry, but this is not postgresql where you where f**ed for ages when your distribution at dist-upgrade shipped a major upgrade and you forgot to dump before i work with MySQL since 2001 and in-place updates followed with 'mysql_upgrade' worked between all vesions including skip a release when i have to dump and reload something is terrible wrong - how do you do that on servers with thounsdands of tables and hundrets of users uninterrupted? and yes my distupgrades from Fedora 9 to Fedora 27 where *online upgrades* followed by a reboot with a downtime of a few seconds while the upgrade itself takes 2-5 minutes on a VMware clusert
2018-06-06 15:20 GMT+03:00 Guillaume Lefranc <guillaume@adishatz.net>:
Hi Michal,
Le mer. 6 juin 2018 à 12:02, Michal Schorm <mschorm@redhat.com> a écrit :
I see a raise of users (of RH products - RHEL and RHSCL mainly) that would like to jump several versions. They had an application build on, let's say, 5.5 (RHEL7 default) and would like to get the features from 10.2 (available in RH software collections - we provide plenty of versions this way). So far, they have to upgrade one by one 5.5->10.0->10.1->10.2; and solve the conflicts at each stage.
That's a waste of time. Such an upgrade is perfectly possible through the means of mysqldump and reload. In-place upgrades might cause some issues because of innodb version changes, but for example, from 10.0 to 10.1, they are rarely an issue because the version of InnoDB hasn't changed. The recommended upgrade path from any version is always the same e.g. dump and reload.
The InnoDB redo log format changed in an incompatible way between MariaDB 10.1 and 10.2, reflecting the change between MySQL 5.6 and 5.7. Due to this change, you cannot kill the old database server and upgrade to a newer one. The new server will refuse to start up on old log file if recovery would be needed. (While you would probably not normally kill the database, there have been some shutdown hang bugs, which could cause an upgrade script to kill the server.) For MariaDB 10.3, the redo and undo log formats were changed again, but we do test in-place upgrades. From MariaDB 10.2 to 10.3, even crash-upgrades have been tested. But I would not guarantee the ability of future versions to upgrade after a crash, because we have plans to change the InnoDB redo log format. We can check that the old log is in a clean state, but I would not want to keep all the code for parsing and applying old logs. -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation
Thanks for the valuable information, Marko. Of course it's always worth doing a full innodb shutdown before an in-place upgrade, so there isn't any transactions to replay. GL Le mer. 6 juin 2018 à 18:21, Marko Mäkelä <marko.makela@mariadb.com> a écrit :
2018-06-06 15:20 GMT+03:00 Guillaume Lefranc <guillaume@adishatz.net>:
Hi Michal,
Le mer. 6 juin 2018 à 12:02, Michal Schorm <mschorm@redhat.com> a écrit :
I see a raise of users (of RH products - RHEL and RHSCL mainly) that would like to jump several versions. They had an application build on, let's say, 5.5 (RHEL7 default) and would like to get the features from 10.2 (available in RH software
collections - >> we provide plenty of versions this way). >> So far, they have to upgrade one by one 5.5->10.0->10.1->10.2; and solve >> the conflicts at each stage. > > That's a waste of time. Such an upgrade is perfectly possible through the > means of mysqldump and reload. In-place upgrades might cause some issues > because of innodb version changes, but for example, from 10.0 to 10.1, they > are rarely an issue because the version of InnoDB hasn't changed. The > recommended upgrade path from any version is always the same e.g. dump and > reload.
The InnoDB redo log format changed in an incompatible way between MariaDB 10.1 and 10.2, reflecting the change between MySQL 5.6 and 5.7. Due to this change, you cannot kill the old database server and upgrade to a newer one. The new server will refuse to start up on old log file if recovery would be needed.
(While you would probably not normally kill the database, there have been some shutdown hang bugs, which could cause an upgrade script to kill the server.)
For MariaDB 10.3, the redo and undo log formats were changed again, but we do test in-place upgrades. From MariaDB 10.2 to 10.3, even crash-upgrades have been tested. But I would not guarantee the ability of future versions to upgrade after a crash, because we have plans to change the InnoDB redo log format. We can check that the old log is in a clean state, but I would not want to keep all the code for parsing and applying old logs. -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation
participants (4)
-
Guillaume Lefranc -
Marko Mäkelä -
Michal Schorm -
Reindl Harald