Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-27274

DROP TABLE after failed IMPORT TABLESPACE fails to delete files

Details

    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

      Attachments

        Issue Links

          Activity

            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.

            marko Marko Mäkelä added a comment - 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.

            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"?

            hholzgra Hartmut Holzgraefe added a comment - 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"?

            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.

            marko Marko Mäkelä added a comment - 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.

            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.

            marko Marko Mäkelä added a comment - 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.

            People

              marko Marko Mäkelä
              hholzgra Hartmut Holzgraefe
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.