Hi,
We are using xtrabackup to backup and restore our database. During restore phase, we use xtrabackup to restore the database, table by table. For each table, an alter table… import tablespace command is called to load the data. However, sometimes the table .ibd file are huge and it takes considerable amount of time, for import tablespace command to finish. During table import, if there is a need shutdown the server, will it cause corruption for ibd files? I would like to understand if there are standard ways to gracefully interrupt an import tablespace operation without any corruptions. If not, would like to know if import tablespace operation is atomic and if so, can a force kill be done to interrupt, without any corruptions to actual data?
Thanks in advance 
In MySQL 8, most DDL operations are supposed to be atomic. Shutting down MySQL during an InnoDB import tablespace sounds dangerous, and would be unsupported.
I would use the typical ctrl-c to cancel the ALTER TABLE IMPORT.
Thanks for replying, currently we are using Mysql5.7 and not yet migrated to Mysql8. Import happens programatically via the application code, sigint(ctrl+c) could be sent, but not sure if it will be honoured give the whole operation seems atomic. Do we know if doing a sigkill corrupts the ibd data?
You would certainly be in a strange/unstable state as part of the pages will have been recorded into the innodb system dictionary, but not all of them if you were to just sigkill mysql.
okay, is there a way to clean up the innodb system dictionary for the partial pages entered before reattempting import?
Not that I am aware of. The internals of InnoDB are not exposed to users. In 5.7, you might be able to DROP TABLE, but InnoDB may tell you the table does not exist even though there is a .ibd file on the disk.
Your best option is to rethink this process to something more stable and more easily to recover from. Tools like mydumper allow you to take logical snapshots and restore single tables.