Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-25083

MariaBackup doesn't work if InnoDB runs with strict_none or strict_innodb

Details

    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.

      Attachments

        Issue Links

          Activity

            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.

            elenst Elena Stepanova added a comment - 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.

            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.

            marko Marko Mäkelä added a comment - 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.

            MDEV-33438 is a further example of a format-related parameter that is not being preserved.

            marko Marko Mäkelä added a comment - MDEV-33438 is a further example of a format-related parameter that is not being preserved.

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.