Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.3.0, 10.4.0, 10.1.38, 10.2.26
-
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!
|
Attachments
Activity
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?
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.