With the current 10.2, TRUNCATE TABLE appears to be crash-safe. I tested as follows:
--source include/have_innodb.inc
|
create table t(a int) engine=innodb;
|
insert into t values(42);
|
truncate table t;
|
select * from t;
|
drop table t;
|
I set a breakpoint on row_truncate_update_table_id and once it was reached (on the TRUNCATE statement), also on row_upd.
The first row_upd() call was for node->table->name = "SYS_TABLES". The second call was for "SYS_COLUMNS". At that point, I did
call log_write_up_to(log_sys->lsn, true)
|
run
|
to kill and restart the server. On the restart, I got a call to row_upd() from truncate_t::update_root_page_no()/row_truncate_update_sys_tables_during_fix_up()/truncate_t::fixup_tables_in_non_system_tablespace (), and then a call to row_truncate_update_table_id() from row_truncate_update_sys_tables_during_fix_up().
The only problem that I see in the TRUNCATE recovery is that is not being skipped if innodb_force_recovery>=3 is specified, and that could cause a lock conflict with the previous attempt of TRUNCATE that was interrupted by a server kill. The TRUNCATE recovery appears to be in the correct place.
So, after all, it is possible be that elenst made the correct conclusion, and that the corruption on SYS_COLUMNS.TABLE_ID mismatch actually was fixed by MDEV-11927.
elenst,
MDEV-11585introduced in 10.2.3 a bug that was fixed in 10.2.5 byMDEV-11927.If manttila originally created the database in 10.2.3 or 10.2.4 and then upgraded to 10.2.5 or later, it is theoretically possible that this is somehow a duplicate of
MDEV-11927.The symptom of
MDEV-11927was that the secondary index on SYS_TABLES.ID was corrupted, because a buffered delete-mark or purge operation was not merged.Here, the symptom is that there is a mismatch reported on SYS_COLUMNS.TABLE_ID, apparently because we have a SYS_TABLE record with no matching records in SYS_COLUMNS. MariaDB or InnoDB should not allow the creation of a table with no columns.
I do not think that this can be a duplicate of
MDEV-11927. When loading a table definition, we would use the clustered index record of SYS_TABLES. So, even if the index on SYS_TABLES.ID was corrupted, it should have nothing to do with this error.