[MDEV-27274] DROP TABLE after failed IMPORT TABLESPACE fails to delete files Created: 2021-12-15  Updated: 2022-04-29  Resolved: 2022-04-29

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.6.5
Fix Version/s: 10.6.8, 10.7.4, 10.8.3, 10.9.1

Type: Bug Priority: Minor
Reporter: Hartmut Holzgraefe Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: CS0257519

Issue Links:
Problem/Incident
is caused by MDEV-25506 Atomic DDL: .frm file is removed and ... Closed
Relates
relates to MDEV-11658 Simpler, faster IMPORT of InnoDB tables Open

 Description   

When something goes wrong during IMPORT TABLESPACE, the table can be dropped, but n

MariaDB [test]> ALTER TABLE t2 IMPORT TABLESPACE;
 
ERROR 1808 (HY000): Schema mismatch (Number of columns don't match, table has 6 columns but the tablespace meta-data file has 7 columns)
 
 
 
MariaDB [test]> DROP TABLE t2;
 
Query OK, 0 rows affected (0.004 sec)
 
 
 
MariaDB [test]> CREATE TABLE t2(id int primary key);
 
ERROR 1005 (HY000): Can't create table `test`.`t2` (errno: 184 "Tablespace already exists")

Problem is that the tablespace was still detached after the failed ALTER, as the new tablespace file did not match, and the old was already gone.

After removing the t2.ibd file manually CREATE works again.

But I think it would be better if either:

  • even on failed import the table "remembers" the failed import attempt, and keeps the .ibd file somewhat linked to the table so that it gets removed on drop (or just brute force delete .ibd file always)
  • let the DROP fail with an appropriate error message if table is in DISCARD stage and an .ibd file by its name is still visible

 Comments   
Comment by Marko Mäkelä [ 2021-12-15 ]

hholzgra, which version is this about? In 10.6, a failed ALTER TABLE…IMPORT TABLESPACE will not remove the .ibd file. The thinking is that the DBA copied that file into the data directory, therefore the DBA owns that file until the import has succeeded.

Perhaps ALTER TABLE t2 DISCARD TABLESPACE should remove the file t2.ibd even if it had not been imported?

The DISCARD/IMPORT workflow is problematic in many ways. MDEV-11658 has been filed for replacing it.

Comment by Hartmut Holzgraefe [ 2021-12-31 ]

Not sure right now whether I only did test on 10.6 at that point, or also earlier.

I do not think that IMPORT TABLESPACE should remove the .ibd file on failure.

But DROP should, even if the table is still in DISCARD state at the time of drop? Or should do not drop the table and just print a warning like "Can't drop table in DISCARD state if .ibd file exists, remove tablespace file and try again"?

Comment by Marko Mäkelä [ 2022-02-15 ]

I think that in 10.6, DROP TABLE will only delete .ibd files that were attached to the data dictionary in the first place. That is similar reasoning as the one for ALTER TABLE … IMPORT TABLESPACE failure.

Before 10.6, DDL was not crash-safe, so we could have more legitimate reasons to delete unknown files on DROP TABLE.

Which version is this bug report for? Use More/Move to change this from Task to Bug, and then you can specify the affected version.

Comment by Marko Mäkelä [ 2022-04-29 ]

Yes, this is a 10.6 regression. The test case for ER_TABLE_SCHEMA_MISMATCH in innodb.import_bugs is compensating for this changed behaviour by explicitly deleting the data file after DROP TABLE. While the current 10.6 behaviour is logical from the InnoDB data dictionary point of view (the data file was never attached to InnoDB, and whoever moved the file to the data directory “owns” it), I agree that it may surprise users. Because the table metadata (without a tablespace ID) still exists in the InnoDB data dictionary after the failed import, DROP TABLE in InnoDB should be able to delete any orphan file that matches the table name.

In MDEV-25506 the implementation was rewritten: Data files that are attached to the table will be deleted after the DDL transaction is durably committed. I think that any detached files can be safely removed already before the durable commit.

Generated at Thu Feb 08 09:51:41 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.