MDEV-41318 Incorrect recovery of FILE_CREATE after FILE_RENAME

[dr-m]

recv_recovery_from_checkpoint_start(): Before applying any page-level log records, invoke recv_rename_files() to replay FILE_RENAME records. In this way, recv_sys_t::recover_deferred() will not overwrite any old data files that had been renamed before a new file was created.

This is a port of b6e3bf0 from #4817. Unfortunately, I was unable to reproduce this outside the test backup.backup_innodb of that branch; that test conveniently reproduces the issue for me under rr record. Reproducibility must depend on some delicate timing. I tried to reproduce this with the following test case:

--source include/have_sequence.inc
--source include/have_innodb.inc

CREATE TABLE a(a INT PRIMARY KEY) ENGINE=InnoDB;
SET GLOBAL innodb_log_file_size=16*1024*1024;
--source include/no_checkpoint_start.inc

CREATE TABLE b(a INT PRIMARY KEY, b CHAR(255), INDEX(b)) ENGINE=INNODB;

--connect dml,localhost,root
BEGIN; INSERT INTO b SELECT seq a, '' b FROM seq_1_to_10000;
--connection default

RENAME TABLE a TO c;
CREATE TABLE a(a INT PRIMARY KEY) ENGINE=InnoDB;

--let CLEANUP_IF_CHECKPOINT=DROP TABLE a,b,c;
--source ../include/no_checkpoint_end.inc

--remove_file $MARIADB_DATADIR/test/a.ibd
--remove_file $MARIADB_DATADIR/test/b.ibd
--move_file $MARIADB_DATADIR/test/c.ibd $MARIADB_DATADIR/test/a.ibd

--source include/start_mysqld.inc

CHECK TABLE a,b,c;
DROP TABLE a,b,c;

The issue in the above test case scenario would be that the new table a would overwrite the data file of the old table a, which is known as c. This is prevented by renaming all data files before starting to apply any changes to them.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}