expand_import failure when importing multiple tablespaces
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS |
Expired
|
Undecided
|
Unassigned |
Bug Description
Using Percona Server 5.5.17
I tried to import multiple tables at the same time.
I executed following queries :
CREATE DATABASE test;
use test;
CREATE TABLE a1 [...];
CREATE TABLE a2 [...];
CREATE TABLE a3 [...];
[...]
ALTER TABLE a1 DISCARD TABLESPACE;
ALTER TABLE a2 DISCARD TABLESPACE;
ALTER TABLE a3 DISCARD TABLESPACE;
[...]
then, I move .ibd and .exp files to folder ./test/
ALTER TABLE a1 IMPORT TABLESPACE; #working
ALTER TABLE a2 IMPORT TABLESPACE; #working
ALTER TABLE a3 IMPORT TABLESPACE; #fail
Log gives me following interesting lines :
InnoDB: Import: The extended import of test/a3 is being started.
InnoDB: Import: 3 indexes have been detected.
InnoDB: Progress in %: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89
InnoDB: Assertion failure in thread 140479148738832 in file rem0rec.c line 561
[...]
/usr/sbin/
/usr/sbin/
/lib64/
/lib64/
/lib64/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/lib64/
/lib64/
/lib64/
[...]
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Error: trying to add tablespace 155 of name './test/a3.ibd'
InnoDB: to the tablespace memory cache, but tablespace
InnoDB: 155 of name './mydb/a56.ibd' already exists in the tablespace
InnoDB: memory cache!
Last lines seems important : there may be a collision in InnoDB tablespace. Is this caused because I created / discard many tables before importing data ?
Can it be solved ?
Actual workaround seems to do the following :
CREATE TABLE a1 [...];
ALTER TABLE a1 DISCARD TABLESPACE;
# copy ibd/exp
ALTER TABLE a1 IMPORT TABLESPACE;
CREATE TABLE a2 [...];
ALTER TABLE a2 DISCARD TABLESPACE;
# copy ibd/exp
ALTER TABLE a2 IMPORT TABLESPACE;
[...]
Olivier,
The crash looks identical to the one reported in https:/ /bugs.launchpad .net/percona- server/ +bug/1000221
Was the table being imported created with MySQL 5.1 or earlier? If so, then unfortunately there's no way to avoid this assertion completely (bug #1000221 has some explanations why it's impossible), though the fix introduced in 5.5.25 a-27.1 will minimize the chances of hitting that assertion, so upgrading to the latest Percona Server release is recommended.
As to the tablespace id collisions on recovery, I think that's the result of the crash on import. It doesn't look related to the order of DISCARD/IMPORT operations.