Vladislav Vaintroub added a comment - 2018-07-24 11:35 - edited The backup does not have to fail, it still can succeed by re-copying the affected tablespace at the end of backup (this technique necessary on other reasons, e.g when recreating tables see MDEV-16791 )

Marko Mäkelä added a comment - 2018-07-25 03:58 True, during backup, the MLOG_INDEX_LOAD record could be handled by copying the affected files (or pages) at the end of the backup. Theoretically, it should suffice to only copy the B-tree pages starting from the root page indicated by each MLOG_INDEX_LOAD record. While this extra copying is taking place, the log would still need to be copied. If the operation is a table rebuild (there is a MLOG_INDEX_LOAD record for the clustered index root page, that is, page number 3), then it is simplest to copy the entire file. When it comes to MDEV-16791 , I believe that for the other cases (files that are renamed or created during the backup) can be handled by processing the already copied redo log in a smarter way, either at the end of mariabackup --backup , or in mariabackup --prepare . All the necessary information should be present in the redo log file.

Thirunarayanan Balathandayuthapani added a comment - 2018-07-25 08:39 Patch looks good to me

Marko Mäkelä added a comment - 2018-07-25 13:15 Thank you for the review. I wrote a test case, which shows that the redo logging is not correct for ROW_FORMAT=COMPRESSED : # see unsupported_redo.test for the opposite ( default ) case --source include/have_innodb.inc --source include/have_sequence.inc   SET GLOBAL innodb_log_optimize_ddl= OFF ;   CREATE TABLE tz(id BIGINT PRIMARY KEY , i INT ) ENGINE=InnoDB /*ROW_FORMAT=COMPRESSED*/ ; INSERT INTO tz(id) select * from seq_1_to_100000; CREATE TABLE tr(id BIGINT PRIMARY KEY , i INT ) ENGINE=InnoDB ROW_FORMAT=REDUNDANT; INSERT INTO tr(id) select * from seq_1_to_100000; CREATE TABLE td(id BIGINT PRIMARY KEY , i INT ) ENGINE=InnoDB; INSERT INTO td(id) select * from seq_1_to_100000;   DELIMITER //; CREATE PROCEDURE a() BEGIN ALTER TABLE tz ADD INDEX (i); ALTER TABLE tr ADD INDEX (i); ALTER TABLE td ADD INDEX (i); END // DELIMITER ;//   let $targetdir=$MYSQLTEST_VARDIR/tmp/backup;   send call a();   --disable_result_log exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$targetdir; --enable_result_log exec $XTRABACKUP --prepare --target-dir=$targetdir;   reap;   -- source include/restart_and_restore.inc   DROP PROCEDURE a;   SHOW CREATE TABLE tz; SHOW CREATE TABLE tr; SHOW CREATE TABLE td; CHECK TABLE tz,tr,td; SELECT COUNT (*) FROM tz; SELECT COUNT (*) FROM tr; SELECT COUNT (*) FROM td;   DROP TABLE tz,tr,td; If the ALTER TABLE included ,FORCE (forcing a rebuild), then this may fail due to files being renamed, and not having MDEV-16791 yet. If the ROW_FORMAT=COMPRESSED is not commented out, then the mariabackup --prepare would fail: InnoDB: Failing assertion: !page || !page_zip || !fil_page_index_page_check(page) I think that we must also test a rebuild of tables that contain BLOBs (and using small innodb_log_file_size ). But testing rebuild would be tricky before we have MDEV-16791 .