[MDEV-15682] mariabackup.unsupported_redo fails in buildbot with wrong result code Created: 2018-03-26  Updated: 2018-03-29  Resolved: 2018-03-29

Status: Closed
Project: MariaDB Server
Component/s: Tests
Affects Version/s: 10.2.14
Fix Version/s: 10.2.15, 10.3.6

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

Issue Links:
Problem/Incident
is caused by MDEV-14545 Backup fails due to MLOG_INDEX_LOAD r... Closed

 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/'



 Comments   
Comment by Marko Mäkelä [ 2018-03-29 ]

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.

Generated at Thu Feb 08 08:23:13 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.