maria-discuss team mailing list archive

[Marko Mäkelä <marko.makela@xxxxxxxxxxx>]

2018-06-06 15:20 GMT+03:00 Guillaume Lefranc <guillaume@xxxxxxxxxxxx>:
> Hi Michal,
>
> Le mer. 6 juin 2018 à 12:02, Michal Schorm <mschorm@xxxxxxxxxx> 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