A crash that leaves behind an InnoDB temporary table with temporary indexes results in an unbootable server
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MySQL Server |
Unknown
|
Unknown
|
|||
Percona Server moved to https://jira.percona.com/projects/PS |
Fix Released
|
High
|
Laurynas Biveinis | ||
5.1 |
Fix Released
|
High
|
Laurynas Biveinis | ||
5.5 |
Fix Released
|
High
|
Laurynas Biveinis | ||
5.6 |
Invalid
|
High
|
Unassigned |
Bug Description
No concrete test case yet, but it needs a temporary table that has at least one index and a server crash that leaves such table behind.
Subsequent server reboots will try to remove such table and fail:
120514 6:43:57 InnoDB: Assertion failure in thread 47327229830816 in file dict0dict.c line 868
InnoDB: Failing assertion: table2 == NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://
InnoDB: about forcing recovery.
Related branches
- Alexey Kopytov (community): Approve
-
Diff: 80 lines (+43/-1)5 files modifiedPercona-Server/mysql-test/suite/innodb/r/percona_bug_999147.result (+10/-0)
Percona-Server/mysql-test/suite/innodb/t/percona_bug_999147-master.opt (+1/-0)
Percona-Server/mysql-test/suite/innodb/t/percona_bug_999147.test (+29/-0)
Percona-Server/storage/innobase/handler/handler0alter.cc (+2/-0)
Percona-Server/storage/innobase/row/row0mysql.c (+1/-1)
- Alexey Kopytov (community): Approve
-
Diff: 80 lines (+43/-1)5 files modifiedPercona-Server/mysql-test/suite/innodb_plugin/r/percona_bug_999147.result (+10/-0)
Percona-Server/mysql-test/suite/innodb_plugin/t/percona_bug_999147-master.opt (+1/-0)
Percona-Server/mysql-test/suite/innodb_plugin/t/percona_bug_999147.test (+29/-0)
Percona-Server/storage/innodb_plugin/handler/handler0alter.cc (+2/-0)
Percona-Server/storage/innodb_plugin/row/row0mysql.c (+1/-1)
summary: |
A crash that leaves behind an InnoDB temporary table with indexes - results in unbootable server + results in an unbootable server |
summary: |
- A crash that leaves behind an InnoDB temporary table with indexes - results in an unbootable server + A crash that leaves behind an InnoDB temporary table with temporary + indexes results in an unbootable server |
To reproduce, add a new crash injection site at the end of non-error path in ha_innobase: :add_index( ) IF("crash_ innodb_ add_index_ after", DBUG_SUICIDE(););
DBUG_EXECUTE_
and then run the following test case:
-- source include/ not_embedded. inc not_valgrind. inc not_crashrep. inc have_debug. inc have_innodb. inc
-- source include/
-- source include/
-- source include/
-- source include/
--disable_warnings
DROP TABLE IF EXISTS t1;
--enable_warnings
SET SESSION expand_ fast_index_ creation= ON;
CREATE TEMPORARY TABLE t1 (a INT, b INT, INDEX(a));
--exec echo "restart" > $MYSQLTEST_ VARDIR/ tmp/mysqld. 1.expect
SET debug=" +d,crash_ innodb_ add_index_ after";
--error 2013
ALTER TABLE t1 ADD INDEX (b);
# Turn on reconnect
--enable_reconnect
# Call script that will poll the server waiting for it to be back online again wait_until_ connected_ again.inc
--source include/
SHOW TABLES;
The only place in InnoDB that uses temporary indexes is the regular table index creation and drop. This code however is not used for the temporary tables, as they are created anew with the final index definitions and then data is copied.
However the Percona Server expanded index creation might use the regular index creation and drop code path in a corner case with expanded fast index creation enabled: when there is an already-existing secondary index on the table, it will be dropped from the new temp table and recreated after copying the data.