[MDEV-21060] mariabackup: preparing a 10.1 backup with 10.2 does not fail and completes successfully Created: 2019-11-15  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: mariabackup
Affects Version/s: 10.3.0, 10.4.0, 10.1.38, 10.2.26
Fix Version/s: 10.4

Type: Bug Priority: Major
Reporter: Rick Pizzi Assignee: Vladislav Lesin
Resolution: Unresolved Votes: 2
Labels: None


 Description   

We have taken a streaming backup from a 10.1 server to a 10.2 server.

mariabackup 10.1.38 was used to take the backup,
then on the target server 10.2.26 was used to prepare it.

This is unsupported and should have errored out, instead the prepare phase
completed successfully (although it did not do any crash recovery).

Output follows.

[root@iaprdmariadbdw01 data]# mariabackup --prepare --target-dir=/data/mysql
mariabackup based on MariaDB server 10.2.26-MariaDB Linux (x86_64)
[00] 2019-11-15 00:02:33 cd to /data/mysql/
[00] 2019-11-15 00:02:33 Loading encryption plugin from file_key_management=file_key_management.so
[00] 2019-11-15 00:02:33 Loading encryption plugin
[00] 2019-11-15 00:02:33     Encryption plugin parameter :  '--innodb_log_checksum_algorithm=INNODB'
[00] 2019-11-15 00:02:33     Encryption plugin parameter :  '--innodb_log_block_size=512'
[00] 2019-11-15 00:02:33     Encryption plugin parameter :  '--plugin_load=file_key_management=file_key_management.so'
[00] 2019-11-15 00:02:33     Encryption plugin parameter :  '--file_key_management_encryption_algorithm=aes_ctr'
[00] 2019-11-15 00:02:33     Encryption plugin parameter :  '--file_key_management_filekey='
[00] 2019-11-15 00:02:33     Encryption plugin parameter :  '--file_key_management_filename=/etc/tdekey'
[00] 2019-11-15 00:02:33     Encryption plugin parameter :  '--innodb_encrypt_log=1'
[00] 2019-11-15 00:02:33     Encryption plugin parameter :  '--prepare'
[00] 2019-11-15 00:02:33     Encryption plugin parameter :  '--target-dir=/data/mysql'
[00] 2019-11-15 00:02:33 This target seems to be not prepared yet.
[00] 2019-11-15 00:02:33 mariabackup: using the following InnoDB configuration for recovery:
[00] 2019-11-15 00:02:33 innodb_data_home_dir = .
[00] 2019-11-15 00:02:33 innodb_data_file_path = ibdata1:12M:autoextend
[00] 2019-11-15 00:02:33 innodb_log_group_home_dir = .
[00] 2019-11-15 00:02:33 InnoDB: Using Linux native AIO
[00] 2019-11-15 00:02:33 Starting InnoDB instance for recovery.
[00] 2019-11-15 00:02:33 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
2019-11-15  0:02:33 140248687855808 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-11-15  0:02:33 140248687855808 [Note] InnoDB: Uses event mutexes
2019-11-15  0:02:33 140248687855808 [Note] InnoDB: Compressed tables use zlib 1.2.7
2019-11-15  0:02:33 140248687855808 [Note] InnoDB: Using Linux native AIO
2019-11-15  0:02:33 140248687855808 [Note] InnoDB: Number of pools: 1
2019-11-15  0:02:33 140248687855808 [Note] InnoDB: Using SSE2 crc32 instructions
2019-11-15  0:02:33 140248687855808 [Note] InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
2019-11-15  0:02:33 140248687855808 [Note] InnoDB: Completed initialization of buffer pool
2019-11-15  0:02:33 140248400250624 [Note] InnoDB: page_cleaner coordinator priority: -20
[00] 2019-11-15 00:02:33 Last binlog file /var/log/mysql/mariadb-bin.000595, position 1065429900
[00] 2019-11-15 00:02:33 mariabackup: Recovered WSREP position: 00000000-0000-0000-0000-000000000000:-1
[00] 2019-11-15 00:02:34 completed OK!



 Comments   
Comment by Marko Mäkelä [ 2019-11-15 ]

mariabackup --prepare should be similar to InnoDB crash recovery. A crash-upgrade from older versions to 10.2 or later is not supported, because the redo log format was changed.

Comment by Marko Mäkelä [ 2019-11-15 ]

The tests innodb.log_corruption and encryption.innodb_encrypt_log_corruption cover various forms of corrupted logs, including attempts to start up from logically empty or nonempty pre-10.2 redo log files. Maybe a variant of them could be added to --suite=mariabackup?

Generated at Thu Feb 08 09:04:17 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.