Bug #95673 | Crash on import tablespace | ||
---|---|---|---|
Submitted: | 6 Jun 2019 13:50 | Modified: | 3 Jul 2019 20:53 |
Reporter: | Daniël van Eeden (OCA) | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S3 (Non-critical) |
Version: | 5.7.26 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | crash, innodb, tts |
[6 Jun 2019 13:50]
Daniël van Eeden
[7 Jun 2019 12:40]
MySQL Verification Team
Hi Daniel, Thank you for your bug report. You wrote yourself that you do not know how to repeat this bug. Can you at least give us the indication of that entire installation, including number of schemas, number of tables or tablespaces in each, types of tables and tablespaces, your configuration. Next, what did that tablespace, to be imported, contained exactly. Next, what is the hardware that you used, OS details etc .... Since this is 5.7, if you could provide us with info on the schema into which you tried to import that tablespace and with the tablespace (compressed) itself, we might try to reproduce it ..... Thanks in advance ......
[10 Jun 2019 16:15]
MySQL Verification Team
Hi Daniel, Just for your information, we are trying to repeat this bug in house. Seems to be a timing issue. We shall see whether we shall succeed.
[13 Jun 2019 9:27]
Xin Wu
This happens when the table has too many partitions. The table crashes contains over 3000 partitions. I could reproduce the crash each time when I import the tablespace. Can you verify if you could trigger it?
[13 Jun 2019 12:57]
MySQL Verification Team
Thank you Mr. Wu, Your input will be forwarded to the team that is trying to reproduce this problem.
[18 Jun 2019 12:32]
MySQL Verification Team
HI Daniel, Wu, So far our efforts in reproducing this bug have failed. Can you upload the output from the SHOW CREATE TABLE for the table in that tablespace ?? Many thanks in advance .....
[18 Jun 2019 12:56]
Xin Wu
I have upload the test table structure. Cheers Xin
[18 Jun 2019 12:58]
MySQL Verification Team
Thank you, Mr. Wu, We see it ......
[21 Jun 2019 12:21]
MySQL Verification Team
Hi Daniel, Mrs. Wu, Our colleague Shane Bester has worked on this test case and here are some of his observations ... Shane used the provided test table, and used lots of rows, 10+ million rows. One thing he noticed is that when FLUSH TABLE test FOR EXPORT is ran, the .cfg files get created and when the import of the table is performed again after discarding tablespace, the auto-increment gets set to 1 for every partition. Not so for your case, it's set to 0 according to the log message. How was this table exported? Is it a clean export and not a dirty/live copy? It is important for us to know this.
[24 Jun 2019 8:59]
Xin Wu
Hello. We have used both xtrabackup to export the tablespace and the clean export with stopped replication and flush table for export method manually. Both failed. xtrabackup: sudo xtrabackup --databases=“app2" --backup --slave-info --stream=tar --target-dir=/mysql/backup/ xtrabackup --prepare --apply-log --export --target-dir=./ and then doing the standard remove tablespace and import tablespace.
[24 Jun 2019 12:42]
MySQL Verification Team
Hi Mrs. Wu, We do not have any experience with xtrabackup nor do we know how it truly functions. So, let us know whether second command executes FLUSH TABLE test FOR EXPORT prior to exporting a tablespace and whether the .cfg files is created during this FLUSH operation ???? Also, after discarding tablespace, when the import of the table is , does the auto-increment gets set to 1 for every partition. So, does every partition get auto-inc set to 1 or not ??? If that is the case, then what you are witnessing is possible a bug in xtrabackup. As far as we could conclude, you have got 0 for the auto-inc, which would lead us to believe that you are experience a bug in xtrabackup.
[25 Jun 2019 7:06]
Xin Wu
Hi It is not only happened during the xtrabackup. Later I removed the xtrabackup, did manually table export. same issue happened again. Source: Flush table xxx for export; copy all the related files to the target server. Target: Alter table xxx discard tablespace; copy the ibd and cfg file over, set correct permission. Alter table xxx import tablespacel; --> mysql crash. As import never works, so I could not check the auto-increment for the new table. Cheers Xin
[25 Jun 2019 12:34]
MySQL Verification Team
Hi Mrs. Wu, You have answered all of our questions except one. Did you use .cfg file when performing IMPORT ??? This is of the vital importance.
[25 Jun 2019 12:50]
Xin Wu
the .cfg file is in the same folder with the .ibd file during the import. I believe that means it is in use?
[25 Jun 2019 12:56]
MySQL Verification Team
Thank you Mrs. Wu, Since we are not able to reproduce your problems even with very large table with the same definition as yours, could you supply us with a compressed tablespace and with .cfg file ??? For upload use the above "Files" tab, or if the compressed file is too large, please use our SFTP directly. If you do not have that tablespaces, then we could try it only with .cfg file. Last, but not least, please explain in more detail how do you exactly import the tablespace ???
[28 Jun 2019 11:58]
MySQL Verification Team
Thank you, Mrs. Wu, We are starting to work with what you have provided .....