For reasons not relevant here, I am forced to do a tablespace discard/import in order to get data from one database to another. The source database is Percona Server 5.7, the target database is Percona XtraDB 5.7. pxc_strict_mode is set to PERMISSIVE for these operations and will be changed to ENFORCING after tables are imported.
I have a large partitioned table that’s a bit over 4GB in 49 files (I didn’t design it…). When importing the tablespace, the command is issued and churns for 30 seconds (almost exactly) and then fails with “Error Code: 2013. Lost connection to MySQL server during query”. It doesn’t appear that anything crashed as I can immediately reconnect, but this happens every time I try to import this table. Other tables of a hundred megabytes or so, that are not partitioned, don’t have any issues.
The mysqld.err log has some confusing messages:
2018-07-16T05:33:03.850023Z 2493 [ERROR] InnoDB: Unable to import tablespace bridgerrf.batchrun /* Partition p_min / because it already exists. Please DISCARD the tablespace before IMPORT.
2018-07-16T05:33:09.566907Z 2493 [ERROR] InnoDB: Unable to import tablespace bridgerrf.batchrun / Partition p_min */ because it already exists. Please DISCARD the tablespace before IMPORT.
Before running the IMPORT, I did the DISCARD (i.e. “ALTER TABLE batchrun DISCARD TABLESPACE;”), so I’m confused about why it would complain the tablespace still exists, and why it would have tried the same operation twice (I didn’t do so manually).
Is this possibly related to the number of partitions or the size of individual partitions? IIRC partitioning is handled by InnoDB so I’m not sure the XtraDB cluster would be a factor. Is there something special I need to do to discard tablespaces for partitioned tables?