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)

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.

Patch looks good to me

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.