Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
When using Mariabackup or MariaDB Backup, users are supposed to use the same version of Mariabackup as the server that is being used. From the KB:
A MariaDB Server version can often be backed up with most other Mariabackup releases in the same release series. For example, MariaDB 10.2.21 and MariaDB 10.2.22 are both in the MariaDB 10.2 release series, so MariaDB Server from MariaDB 10.2.21 could be backed up by Mariabackup from MariaDB 10.2.22, or vice versa.
However, occasionally, a MariaDB Server or Mariabackup release will include bug fixes that will break compatibility with previous releases. For example, the fix for
MDEV-13564changed the InnoDB redo log format in MariaDB 10.2.19 which broke compatibility with previous releases. To be safest, a MariaDB Server release should generally be backed up with the Mariabackup release that has the same version number.
However, Mariabackup doesn't actually check the server version and throw an error, if it is different.
In some cases, the --backup step might even seem to succeed, and then it will only fail during the --prepare step.
If the Mariabackup version is newer than the server, then the user might see an Upgrade after a crash is not supported error during the --backup step, like this:
$ sudo mariabackup --backup \
|
> --target-dir=/tmp/backup/ \
|
> --user=root \
|
> --socket=/tmp/mysql.sock
|
[00] 2020-06-08 21:34:18 Connecting to MySQL server host: localhost, user: root, password: not set, port: not set, socket: /tmp/mysql.sock
|
[00] 2020-06-08 21:34:18 Using server version 10.4.13-MariaDB
|
mariabackup based on MariaDB server 10.5.2-0-MariaDB Linux (x86_64)
|
[00] 2020-06-08 21:34:18 uses posix_fadvise().
|
[00] 2020-06-08 21:34:18 cd to /tmp/mariadb/
|
[00] 2020-06-08 21:34:18 open files limit requested 0, set to 1024
|
[00] 2020-06-08 21:34:18 mariabackup: using the following InnoDB configuration:
|
[00] 2020-06-08 21:34:18 innodb_data_home_dir =
|
[00] 2020-06-08 21:34:18 innodb_data_file_path = ibdata1:12M:autoextend
|
[00] 2020-06-08 21:34:18 innodb_log_group_home_dir = ./
|
[00] 2020-06-08 21:34:18 InnoDB: Using Linux native AIO
|
2020-06-08 21:34:18 0 [Note] InnoDB: Number of pools: 1
|
2020-06-08 21:34:18 0 [ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was created with MariaDB 10.4.13.
|
[00] 2020-06-08 21:34:18 Error: cannot read redo log header
|
If the Mariabackup version is older than the server, then the user might see an Unsupported redo log format error during the --prepare step, like this:
$ sudo ./bin/mariabackup --prepare \
|
> --target-dir=/tmp/backup/
|
./bin/mariabackup based on MariaDB server 10.4.13-MariaDB Linux (x86_64)
|
[00] 2020-06-08 21:38:05 cd to /tmp/backup/
|
[00] 2020-06-08 21:38:05 This target seems to be not prepared yet.
|
[00] 2020-06-08 21:38:05 mariabackup: using the following InnoDB configuration for recovery:
|
[00] 2020-06-08 21:38:05 innodb_data_home_dir = .
|
[00] 2020-06-08 21:38:05 innodb_data_file_path = ibdata1:12M:autoextend
|
[00] 2020-06-08 21:38:05 innodb_log_group_home_dir = .
|
[00] 2020-06-08 21:38:05 InnoDB: Using Linux native AIO
|
[00] 2020-06-08 21:38:05 Starting InnoDB instance for recovery.
|
[00] 2020-06-08 21:38:05 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
|
2020-06-08 21:38:05 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
|
2020-06-08 21:38:05 0 [Note] InnoDB: Uses event mutexes
|
2020-06-08 21:38:05 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
|
2020-06-08 21:38:05 0 [Note] InnoDB: Number of pools: 1
|
2020-06-08 21:38:05 0 [Note] InnoDB: Using SSE2 crc32 instructions
|
./bin/mariabackup: O_TMPFILE is not supported on /tmp (disabling future attempts)
|
2020-06-08 21:38:05 0 [Note] InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
|
2020-06-08 21:38:05 0 [Note] InnoDB: Completed initialization of buffer pool
|
2020-06-08 21:38:05 0 [Note] InnoDB: page_cleaner coordinator priority: -20
|
2020-06-08 21:38:05 0 [ERROR] InnoDB: Unsupported redo log format. The redo log was created with Backup 10.5.2-0-MariaDB.
|
2020-06-08 21:38:05 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
|
[00] FATAL ERROR: 2020-06-08 21:38:05 mariabackup: innodb_init() returned 11 (Generic error).
|
I think it would be a good idea for Mariabackup to have a better version check. For example, if the user is using Mariabackup 10.4, then it should throw an error if the server isn't running MariaDB Server 10.4.
Attachments
Issue Links
- relates to
-
MDEV-23394 mariadb --prepare --export fails with "Upgrade after crash is not supported" and error 11
-
- Open
-
This was implemented on Percona Xtrabackup on the following commits:
The patches looks quite self-contained, but I am not familiar with the differences between the codebases (logging, etc.)
This will make backups fail rather than getting potentially corrupt when using a lower version of mariabackup when preparing the backup.
The rationale is that, while we try to make sure we always use the same version for MariaDB server and MariaBackup, mistakes can happen and having the check builtin on the preparation rather than on automation layer will be much safer.
Important: please do not confuse --no-server-version-check with --no-version-check, the first is the (disabling) of the useful check (enabled by default), the second is the percona call-home functionality that is already disabled on MariaBackup. We want the first.