Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.6.3, 10.6.4, 10.6.5, 10.7.1
Description
The data directory data_copy.tar.xz
fails to recover:
sql/mariadbd --innodb-page-size=4k --datadir $(pwd)/data_copy --skip-stack-trace
|
|
10.6 |
…
|
2021-11-11 17:42:18 0 [Note] InnoDB: Completed initialization of buffer pool
|
2021-11-11 17:42:18 0 [Note] InnoDB: Setting O_DIRECT on file ./ibdata1 failed
|
2021-11-11 17:42:18 0 [ERROR] [FATAL] InnoDB: SYS_VIRTUAL.TABLE_ID mismatch
|
The error means that we failed to find a record in SYS_VIRTUAL for an uncommitted table.
At the time of the last InnoDB log write the server was executing TRUNCATE TABLE on the table and dropping the original (possibly nonempty) copy of the table:
#21 0x00005640eaa842f0 in fts_drop_tables (trx=0x7f6217dc9248, table=...) at /data/Server/bb-10.6-markoQ/storage/innobase/fts/fts0fts.cc:1688
|
#22 0x00005640eaa02e94 in trx_t::drop_table (this=0x7f6217dc9248, table=...) at /data/Server/bb-10.6-markoQ/storage/innobase/dict/drop.cc:191
|
#23 0x00005640ea36c7eb in ha_innobase::truncate (this=0x61d0002e4ab8) at /data/Server/bb-10.6-markoQ/storage/innobase/handler/ha_innodb.cc:13879
|
This is right after the following step in trx_t::drop_table():
if (dict_sys.sys_virtual) |
{
|
pars_info_t *info= pars_info_create();
|
pars_info_add_ull_literal(info, "id", table.id); |
if (dberr_t err= que_eval_sql(info, |
"PROCEDURE DROP_VIRTUAL() IS\n" |
"BEGIN\n" |
"DELETE FROM SYS_VIRTUAL" |
" WHERE TABLE_ID=:id;\n" |
"END;\n", this)) |
return err; |
}
|
So, it is very well possible that SYS_VIRTUAL entries will not exist for an #sql-ib table (which will by design of MDEV-25506 always be uncommitted), and the recovery has to be adjusted.
The server would crash even with {{ --innodb-force-recovery=4}}.