This section describes how to copy file-per-table tablespaces from one database server to another, otherwise known as the Transportable Tablespaces feature.
For information about other InnoDB table
copying methods, see Section 14.8.4, “Moving or Copying InnoDB Tables to Another Machine”.
There are many reasons why you might copy an
InnoDB
file-per-table
tablespace to a different database server:
To run reports without putting extra load on a production server.
To set up identical data for a table on a new slave server.
To restore a backed-up version of a table after a problem or mistake.
As a faster way of moving data around than importing the results of a mysqldump command. The data is available immediately, rather than having to be re-inserted and the indexes rebuilt.
To move a file-per-table tablespace to a server with storage medium that better suits system requirements. For example, you may want to have busy tables on an SSD device, or large tables on a high-capacity HDD device.
The tablespace copy procedure is only possible when
innodb_file_per_table is set
to ON, which is the default setting as of
MySQL 5.6.6. Tables residing in the shared system tablespace
cannot be quiesced.
When a table is quiesced, only read-only transactions are allowed on the affected table.
When importing a tablespace, the page size must match the page size of the importing instance.
DISCARD TABLESPACE is not supported for
partitioned tables meaning that transportable tablespaces is
also unsupported. If you run
ALTER
TABLE ... DISCARD TABLESPACE on a partitioned table,
the following error is returned: ERROR 1031
(HY000): Table storage engine for 'part' doesn't have this
option.
DISCARD TABLESPACE is not supported for
tablespaces with a parent-child (primary key-foreign key)
relationship when
foreign_key_checks is set to
1. Before discarding a tablespace for
parent-child tables, set
foreign_key_checks=0.
ALTER TABLE ...
IMPORT TABLESPACE does not enforce foreign key
constraints on imported data. If there are foreign key
constraints between tables, all tables should be exported at
the same (logical) point in time.
ALTER TABLE ...
IMPORT TABLESPACE does not require a
.cfg metadata file to import a
tablespace. However, metadata checks are not performed when
importing without a .cfg file, and a
warning similar to the following will be issued:
Message: InnoDB: IO Read error: (2, No such file or directory) Error opening '.\ test\t.cfg', will attempt to import without schema verification 1 row in set (0.00 sec)
The ability to import without a .cfg file
may be more convenient when no schema mismatches are expected.
Additionally, the ability to import without a
.cfg file could be useful in crash
recovery scenarios in which metadata cannot be collected from
an .ibd file.
In MySQL 5.6 or later, importing a tablespace file from another server works if both servers have GA (General Availability) status and their versions are within the same series. Otherwise, the file must have been created on the server into which it is imported.
In replication scenarios,
innodb_file_per_table must be
set to ON on both the master and slave.
On Windows, InnoDB stores database,
tablespace, and table names internally in lowercase. To avoid
import problems on case-sensitive operating systems such as
Linux and UNIX, create all databases, tablespaces, and tables
using lowercase names. A convenient way to accomplish this is
to add the following line to the [mysqld]
section of your my.cnf or
my.ini file before creating databases,
tablespaces, or tables:
[mysqld] lower_case_table_names=1
This procedure demonstrates how to copy a table stored in a file-per-table tablespace from a running MySQL server instance to another running instance. The same procedure with minor adjustments can be used to perform a full table restore on the same instance.
On the source server, create a table if one does not already exist:
mysql> use test; mysql> CREATE TABLE t(c1 INT) engine=InnoDB;
On the destination server, create a table if one does not exist:
mysql> use test; mysql> CREATE TABLE t(c1 INT) engine=InnoDB;
On the destination server, discard the existing tablespace.
(Before a tablespace can be imported,
InnoDB must discard the tablespace that is
attached to the receiving table.)
mysql> ALTER TABLE t DISCARD TABLESPACE;
On the source server, run
FLUSH
TABLES ... FOR EXPORT to quiesce the table and
create the .cfg metadata file:
mysql> use test; mysql> FLUSH TABLES t FOR EXPORT;
The metadata (.cfg) file is created in
the InnoDB data directory.
FLUSH TABLES ... FOR
EXPORT is available as of MySQL 5.6.6. The
statement ensures that changes to the named tables have been
flushed to disk so that binary table copies can be made
while the server is running. When
FLUSH TABLES ... FOR
EXPORT is run, InnoDB produces
a .cfg file in the same database
directory as the table. The .cfg file
contains metadata used for schema verification when
importing the tablespace file.
Copy the .ibd file and
.cfg metadata file from the source server
to the destination server. For example:
shell> scp/path/to/datadir/test/t.{ibd,cfg} destination-server:/path/to/datadir/test
The .ibd file and
.cfg file must be copied before
releasing the shared locks, as described in the next step.
On the source server, use
UNLOCK
TABLES to release the locks acquired by
FLUSH
TABLES ... FOR EXPORT:
mysql> use test; mysql> UNLOCK TABLES;
On the destination server, import the tablespace:
mysql> use test; mysql> ALTER TABLE t IMPORT TABLESPACE;
The ALTER TABLE
... IMPORT TABLESPACE feature does not enforce
foreign key constraints on imported data. If there are
foreign key constraints between tables, all tables should be
exported at the same (logical) point in time. In this case
you would stop updating the tables, commit all transactions,
acquire shared locks on the tables, and then perform the
export operation.
The following information describes internals and error log messaging for the transportable tablespaces copy procedure.
When ALTER TABLE ...
DISCARD TABLESPACE is run on the destination instance:
The table is locked in X mode.
The tablespace is detached from the table.
When FLUSH TABLES ... FOR
EXPORT is run on the source instance:
The table being flushed for export is locked in shared mode.
The purge coordinator thread is stopped.
Dirty pages are synchronized to disk.
Table metadata is written to the binary
.cfg file.
Expected error log messages for this operation:
2013-07-18 14:47:31 34471 [Note] InnoDB: Sync to disk of '"test"."t"' started. 2013-07-18 14:47:31 34471 [Note] InnoDB: Stopping purge 2013-07-18 14:47:31 34471 [Note] InnoDB: Writing table metadata to './test/t.cfg' 2013-07-18 14:47:31 34471 [Note] InnoDB: Table '"test"."t"' flushed to disk
When UNLOCK
TABLES is run on the source instance:
The binary .cfg file is deleted.
The shared lock on the table or tables being imported is released and the purge coordinator thread is restarted.
Expected error log messages for this operation:
2013-07-18 15:01:40 34471 [Note] InnoDB: Deleting the meta-data file './test/t.cfg' 2013-07-18 15:01:40 34471 [Note] InnoDB: Resuming purge
When ALTER TABLE ...
IMPORT TABLESPACE is run on the destination instance,
the import algorithm performs the following operations for each
tablespace being imported:
Each tablespace page is checked for corruption.
The space ID and log sequence numbers (LSNs) on each page are updated
Flags are validated and LSN updated for the header page.
Btree pages are updated.
The page state is set to dirty so that it will be written to disk.
Expected error log messages for this operation:
2013-07-18 15:15:01 34960 [Note] InnoDB: Importing tablespace for table 'test/t' that was exported from host 'ubuntu'
2013-07-18 15:15:01 34960 [Note] InnoDB: Phase I - Update all pages
2013-07-18 15:15:01 34960 [Note] InnoDB: Sync to disk
2013-07-18 15:15:01 34960 [Note] InnoDB: Sync to disk - done!
2013-07-18 15:15:01 34960 [Note] InnoDB: Phase III - Flush changes to disk
2013-07-18 15:15:01 34960 [Note] InnoDB: Phase IV - Flush complete
You may also receive a warning that a tablespace is discarded
(if you discarded the tablespace for the destination table) and
a message stating that statistics could not be calculated due to
a missing .ibd file:
2013-07-18 15:14:38 34960 [Warning] InnoDB: Table "test"."t" tablespace is set as discarded. 2013-07-18 15:14:38 7f34d9a37700 InnoDB: cannot calculate statistics for table "test"."t" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html