[MDEV-25083] MariaBackup doesn't work if InnoDB runs with strict_none or strict_innodb Created: 2021-03-08  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: mariabackup, Storage Engine - InnoDB
Affects Version/s: 10.2, 10.3, 10.4, 10.5, 10.6
Fix Version/s: 10.4, 10.5

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-25105 Remove innodb_checksum_algorithm valu... Closed
relates to MDEV-25106 Issue deprecation warnings for innodb... Closed

 Description   

If the server runs with innodb-checksum-algorithm=strict_none or strict_innodb, even the most primitive backup created by MariaBackup does not work, the server reports corruption upon an attempt to start on a restored backup.

I guess it's because MariaBackup always writes innodb_checksum_algorithm=crc32 into its config in the backup directory, regardless of the mode on the server.

10.2 545cba13

2021-03-08 16:14:45 140510713141056 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace innodb_system page [page id: space=0, page number=5]. You may have to recover from a backup.
2021-03-08 16:14:45 140510713141056 [Note] InnoDB: Uncompressed page, stored checksum in field1 3624551581, calculated checksums for field1: crc32 3624551581, innodb 3679777192,  page type 7 == TRX_SYS.none 3735928559, stored checksum in field2 3624551581, calculated checksums for field2: crc32 3624551581, innodb 3081167225, none 3735928559,  page LSN 0 1628836, low 4 bytes of LSN at page end 1628836, page number (if stored to page already) 5, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a transaction system page
2021-03-08 16:14:45 140510713141056 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2021-03-08 16:14:45 140510713141056 [ERROR] [FATAL] InnoDB: Aborting because of a corrupt database page.
210308 16:14:45 [ERROR] mysqld got signal 6 ;
 
#6  0x0000563ad7ba3465 in ib::fatal::~fatal (this=0x7fff88987cc0, __in_chrg=<optimized out>) at /data/src/10.2/storage/innobase/ut/ut0ut.cc:649
#7  0x0000563ad7c09402 in buf_page_io_complete (bpage=0x7fcb2d98f000, dblwr=false, evict=false) at /data/src/10.2/storage/innobase/buf/buf0buf.cc:6095
#8  0x0000563ad7c2d492 in buf_read_page_low (err=0x7fff889880b4, sync=true, type=0, mode=132, page_id=..., page_size=..., unzip=false, ignore_missing_space=false) at /data/src/10.2/storage/innobase/buf/buf0rea.cc:215
#9  0x0000563ad7c2dca0 in buf_read_page (page_id=..., page_size=...) at /data/src/10.2/storage/innobase/buf/buf0rea.cc:412
#10 0x0000563ad7c03faa in buf_page_get_low (page_id=..., page_size=..., rw_latch=2, guess=0x0, mode=10, file=0x563ad814aac8 "/data/src/10.2/storage/innobase/include/trx0sys.ic", line=77, mtr=0x7fff889885d0, err=0x0) at /data/src/10.2/storage/innobase/buf/buf0buf.cc:4315
#11 0x0000563ad7c056b6 in buf_page_get_gen (page_id=..., page_size=..., rw_latch=2, guess=0x0, mode=10, file=0x563ad814aac8 "/data/src/10.2/storage/innobase/include/trx0sys.ic", line=77, mtr=0x7fff889885d0, err=0x0) at /data/src/10.2/storage/innobase/buf/buf0buf.cc:4835
#12 0x0000563ad7b837e1 in trx_sysf_get (mtr=0x7fff889885d0) at /data/src/10.2/storage/innobase/include/trx0sys.ic:77
#13 0x0000563ad7b84f75 in trx_rseg_get_n_undo_tablespaces (space_ids=0x7fff88988b80) at /data/src/10.2/storage/innobase/trx/trx0rseg.cc:349
#14 0x0000563ad7b42120 in srv_undo_tablespaces_init (create_new_db=false) at /data/src/10.2/storage/innobase/srv/srv0start.cc:861
#15 0x0000563ad7b45ce8 in innobase_start_or_create_for_mysql () at /data/src/10.2/storage/innobase/srv/srv0start.cc:2092
#16 0x0000563ad798c599 in innobase_init (p=0x563ada4ecd90) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:4298
#17 0x0000563ad7789260 in ha_initialize_handlerton (plugin=0x563ada4dfbb8) at /data/src/10.2/sql/handler.cc:555
#18 0x0000563ad751d2b9 in plugin_initialize (tmp_root=0x7fff8898e4c0, plugin=0x563ada4dfbb8, argc=0x563ad8842568 <remaining_argc>, argv=0x563ada3aa040, options_only=false) at /data/src/10.2/sql/sql_plugin.cc:1417
#19 0x0000563ad751df5f in plugin_init (argc=0x563ad8842568 <remaining_argc>, argv=0x563ada3aa040, flags=2) at /data/src/10.2/sql/sql_plugin.cc:1698
#20 0x0000563ad7410609 in init_server_components () at /data/src/10.2/sql/mysqld.cc:5387
#21 0x0000563ad7411729 in mysqld_main (argc=146, argv=0x563ada3aa040) at /data/src/10.2/sql/mysqld.cc:5996
#22 0x0000563ad740641d in main (argc=24, argv=0x7fff8898ece8) at /data/src/10.2/sql/main.cc:25

Run with --mysqld=--innodb-checksum-algorithm=strict_innodb

--source include/have_innodb.inc
 
CREATE TABLE t (pk INT AUTO_INCREMENT PRIMARY KEY, i INT) ENGINE=InnoDB;
INSERT INTO t VALUES (1,1),(2,2);
 
--echo # Running backup
--exec $XTRABACKUP --backup --target-dir=$MYSQLTEST_VARDIR/mbackup_backup --protocol=tcp --port=$MASTER_MYPORT --user=root
--echo # Running prepare
--exec $XTRABACKUP --prepare --target-dir=$MYSQLTEST_VARDIR/mbackup_backup
--echo # Running restore
--exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --copy-back --datadir=$MYSQLTEST_VARDIR/mbackup_restore --target-dir=$MYSQLTEST_VARDIR/mbackup_backup
--echo # Restarting on the restored datadir
--let $restart_parameters= --datadir=$MYSQLTEST_VARDIR/mbackup_restore
--source include/restart_mysqld.inc
 
# Cleanup
--echo # Restarting on the original datadir
--let $restart_parameters=
--source include/restart_mysqld.inc
 
DROP TABLE t;

Reproducible on 10.2-10.6, debug and non-debug.



 Comments   
Comment by Elena Stepanova [ 2021-03-08 ]

To clarify, the issue is assigned to marko merely for an expert opinion – whether it is worth fixing, as innodb and none checksum algorithms are outdated.

If they are going to remain available in future versions, it needs to be fixed somehow – either by fixing MariaBackup config generation, or by not allowing MariaBackup to backup servers with strict_innodb or strict_none. It's better if MariaBackup explicitly refuses to operate than if it produces backups which will turn out to be unusable.

If the old algorithms are going to be deprecated/removed, I think it's okay just to document it as MariaBackup limitation.

Comment by Marko Mäkelä [ 2021-03-11 ]

MDEV-25106 introduces deprecation warnings in 10.3 for the unsafe innodb_checksum_algorithm values none and innodb. MDEV-25105 in 10.6 will reject those values, by default forcing old files to use innodb_checksum_algorithm=crc32 (tolerating also the unsafe algorithms) and new files to use the safest and most efficient variant innodb_checksum_algorithm=full_crc32 that was introduced in 10.4.

Even though those changes appear to address the immediate problem, I think that we should keep this report open until someone has ensured that mariabackup will always preserve all relevant configuration parameters.

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