data_copy.tar.xz trips a debug assertion in InnoDB crash recovery.
If the failing assertion is removed, the dataset will recover, and the output of INFORMATION_SCHEMA.INNODB_SYS_TABLES will be consistent with .frm files.
In the rr replay trace of the server that was killed before the failed recovery, there was a successfully completed ALTER TABLE…DROP INDEX operation that correctly caused recovery to report trx_id=1111. A subsequent ALTER TABLE on the same table was actually a no-op for InnoDB, and it did not finish before the server was killed. For that operation, ha_innobase::prepare_inplace_alter_table() returned early:
This is why ha_innobase::table_version() ended up reporting m_prebuilt->trx_id=1088, which was recovered as create_id.
The original purpose of row_prebuilt_t::trx_id and dict_table_t::def_trx_id was to prevent recently created secondary indexes or rebuilt tables from being (first-time) accessed by transactions whose read views were created before the ALTER TABLE operation was started and finished. In
MDEV-25180, the purpose was extended to cover the recovery of ALTER TABLE, to determine whether an operation was committed inside the storage engine.
Because the being-recovered ALTER TABLE operation was a no-op for InnoDB, it does not really matter which table definition version was recovered. It could be useful to retain the debug assertion, so that it can catch more genuine errors in the future.
If I patch the little-endian 32-bit value 0x440 (1088) at byte offset 0x3020 in the data_copy/ddl_recovery.log file that is contained in data_copy.tar.xz to 0, then the data directory will recover just fine without tripping the assertion. This should be equivalent to having run the killed server with the following fix:
The only other DBUG_RETURN(false) in that function can also set m_prebuilt->trx_id to 0, so this should be fine from the correctness point of view.
I tried to create a test case for reproducing this, but failed, with both values of innodb_file_per_table. Here is my attempt:
As far as I can tell, this bug does not affect the correctness of recovery for non-debug builds.