maria-discuss team mailing list archive

[Guillaume Lefranc <guillaume@xxxxxxxxxxxx>]

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@xxxxxxxxxxx> a
écrit :

> 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
>