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

mariabackup.unsupported_redo fails in buildbot with wrong result code

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.2.14
    • 10.2.15, 10.3.6
    • Tests
    • None

    Description

      http://buildbot.askmonty.org/buildbot/builders/win32-debug/builds/8003/steps/test/logs/stdio

      mariabackup.unsupported_redo 'innodb'    w2 [ fail ]
              Test ended at 2018-03-26 12:49:32
       
      CURRENT_TEST: mariabackup.unsupported_redo
      mysqltest: At line 26: command "$XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf  --backup --target-dir=$basedir" succeeded - should have failed with errno 1...
       
      The result from queries just before the failure was:
      call mtr.add_suppression("InnoDB: New log files created");
      call mtr.add_suppression("InnoDB: Operating system error number .* in a file operation");
      call mtr.add_suppression("InnoDB: The error means the system cannot find the path specified");
      call mtr.add_suppression("InnoDB: If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them");
      call mtr.add_suppression("InnoDB: Ignoring tablespace for `test`\\.`t21` because it could not be opened");
      call mtr.add_suppression("InnoDB: Cannot open datafile for read-only: ");
      call mtr.add_suppression("Table .* in the InnoDB data dictionary has tablespace id .*, but tablespace with that id or name does not exist");
      CREATE TABLE t1(i INT PRIMARY KEY auto_increment, a int) ENGINE INNODB;
      SET GLOBAL INNODB_FAST_SHUTDOWN = 0;
      ALTER TABLE t1 FORCE, ALGORITHM=INPLACE;
      # Fails during full backup
       
       - saving 'D:/win32-debug/build/mysql-test/var/2/log/mariabackup.unsupported_redo-innodb/' to 'D:/win32-debug/build/mysql-test/var/log/mariabackup.unsupported_redo-innodb/'
      

      Attachments

        Issue Links

          Activity

            I believe that this is cause by one or two things:

            1. Unless innodb_flush_log_at_trx_commit=1, there is nothing that forces the ALTER TABLE statement to be actually written to the redo log before mariabackup --backup starts to execute.
            2. If InnoDB executes an extra redo log checkpoint, discarding the log for the ALTER TABLE statement, then mariabackup --backup would not see the MLOG_INDEX_LOAD record either.

            In an attempt to prevent an extra checkpoint from occurring, the test is executing a slow shutdown and restart right before the ALTER TABLE. This is not a full guarantee. Perhaps a slightly better guarantee would be to use a debug-only variable to force a checkpoint right before the ALTER TABLE, but then the test would require a debug server to run. We want to avoid unnecessary debug instrumentation and test the release builds too.

            It seems that this test needs to implement something similar to no_checkpoint_end.inc, so that the test can be skipped if an unwanted checkpoint occurred. This would involve the following:

            1. --source no_checkpoint_start.inc before the ALTER TABLE, to assign the environment variable CHECKPOINT_LSN.
            2. Run mariabackup --backup, and save the return value. If it returns 0, then read the backed-up log file (like no_checkpoint_start.inc does), and if there is a checkpoint mismatch, execute cleanup actions.

            It could be simplest to use no_checkpoint_end.inc. Maybe we could let no_checkpoint_kill=1 to skip the kill_mysqld.inc and start_mysqld.inc in that file. We’d also need --let CLEANUP_IF_CHECKPOINT=DROP TABLE t1; of course.

            marko Marko Mäkelä added a comment - I believe that this is cause by one or two things: Unless innodb_flush_log_at_trx_commit=1 , there is nothing that forces the ALTER TABLE statement to be actually written to the redo log before mariabackup --backup starts to execute. If InnoDB executes an extra redo log checkpoint, discarding the log for the ALTER TABLE statement, then mariabackup --backup would not see the MLOG_INDEX_LOAD record either. In an attempt to prevent an extra checkpoint from occurring, the test is executing a slow shutdown and restart right before the ALTER TABLE . This is not a full guarantee. Perhaps a slightly better guarantee would be to use a debug-only variable to force a checkpoint right before the ALTER TABLE , but then the test would require a debug server to run. We want to avoid unnecessary debug instrumentation and test the release builds too. It seems that this test needs to implement something similar to no_checkpoint_end.inc , so that the test can be skipped if an unwanted checkpoint occurred. This would involve the following: --source no_checkpoint_start.inc before the ALTER TABLE , to assign the environment variable CHECKPOINT_LSN . Run mariabackup --backup , and save the return value. If it returns 0, then read the backed-up log file (like no_checkpoint_start.inc does), and if there is a checkpoint mismatch, execute cleanup actions. It could be simplest to use no_checkpoint_end.inc . Maybe we could let no_checkpoint_kill=1 to skip the kill_mysqld.inc and start_mysqld.inc in that file. We’d also need --let CLEANUP_IF_CHECKPOINT=DROP TABLE t1; of course.

            People

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

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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