Starting with MariaDB 10.5 Galera SST will fail with
[ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was created with Backup 10.4.34-MariaDB
when using the rsync or mariabackup SST method, as both methods basically transfer a physical copy of the datadir, requiring recovery on the joiner side to get to a clean state.
Not supporting recovery from earlier major versions prevents these two SST methods from working, only the mysqldump method can still function automatically.
As a workaround one can do:
"manual SST" using Mariabackup, with both the --backup and --prepare steps performed on the donor side before copying over the clean prepared state over to the joiner
having new server version, but older mariabackup version, installed on the joiner
This also affects rolling cluster upgrades to a new major release in cases where an upgraded node can't re-join using IST
Attachments
Issue Links
duplicates
MDEV-31506Updating cluster to a new major version Reports Upgrade after a crash is not supported with rsync sst
Confirmed
MDEV-31536Galera mariadb-backup to work as SST between major versions
Open
relates to
MDEV-27437Galera snapshot transfer fails to upgrade between some major versions
Starting with MariaDB 10.5 Galera SST will fail with
{{[ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was created with Backup 10.4.34-MariaDB}}
when using the {{rsync}} or {{mariabackup}} SST method, as both methods basically transfer a physical copy of the datadir, requiring recovery on the joiner side to get to a clean state.
Not supporting recovery from earlier major versions prevents these two SST methods from working, only the {{mysqldump}} method can still function automatically.
As a workaround one can do:
* "manual SST" using Mariabackup, with both the --backup and --prepare steps performed on the donor side before copying over the clean prepared state over to the joiner
* having new server version, but older mariabackup version, installed on the joiner
Starting with MariaDB 10.5 Galera SST will fail with
{{[ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was created with Backup 10.4.34-MariaDB}}
when using the {{rsync}} or {{mariabackup}} SST method, as both methods basically transfer a physical copy of the datadir, requiring recovery on the joiner side to get to a clean state.
Not supporting recovery from earlier major versions prevents these two SST methods from working, only the {{mysqldump}} method can still function automatically.
As a workaround one can do:
* "manual SST" using Mariabackup, with both the --backup and --prepare steps performed on the donor side before copying over the clean prepared state over to the joiner
* having new server version, but older mariabackup version, installed on the joiner
This also affects rolling cluster upgrades to a new major release in cases where an upgraded node can't re-join using IST
It turns out that MDEV-27437 had been filed for a quite similar problem.
I remember suggesting at some point that there should be a special snapshot method that would prepare or recover from the non-logical backup on an intermediate node that runs the same software version as the donor. In that way, the joiner would be able to start with a logically empty write-ahead log.
Marko Mäkelä
added a comment - It turns out that MDEV-27437 had been filed for a quite similar problem.
I remember suggesting at some point that there should be a special snapshot method that would prepare or recover from the non-logical backup on an intermediate node that runs the same software version as the donor. In that way, the joiner would be able to start with a logically empty write-ahead log.
Bug
Major
MDEV-31536 Galera mariadb-backup to work as SST between major versions
It turns out that
MDEV-27437had been filed for a quite similar problem.I remember suggesting at some point that there should be a special snapshot method that would prepare or recover from the non-logical backup on an intermediate node that runs the same software version as the donor. In that way, the joiner would be able to start with a logically empty write-ahead log.