This section describes techniques for moving or copying some or all
InnoDB tables to a different server or instance.
For example, you might move an entire MySQL instance to a larger,
faster server; you might clone an entire MySQL instance to a new
replication slave server; you might copy individual tables to
another instance to develop and test an application, or to a data
warehouse server to produce reports.
InnoDB always stores database and
table names internally in lowercase. To move databases in a binary
format from Unix to Windows or from Windows to Unix, create all
databases and tables using lowercase names. A convenient way to
accomplish this is to add the following line to the
[mysqld] section of your
before creating any databases or tables:
Techniques for moving or copying
The transportable tablespaces feature uses
TABLES ... FOR EXPORT to ready
tables for copying from one server instance to another. To use this
InnoDB tables must be created with
innodb_file_per_table set to
ON so that each
has its own tablespace. For usage information, see
Section 14.7.6, “Copying File-Per-Table Tablespaces to Another Instance”.
The MySQL Enterprise Backup product lets you back up a running MySQL database with minimal disruption to operations while producing a consistent snapshot of the database. When MySQL Enterprise Backup is copying tables, reads and writes can continue. In addition, MySQL Enterprise Backup can create compressed backup files, and back up subsets of tables. In conjunction with the MySQL binary log, you can perform point-in-time recovery. MySQL Enterprise Backup is included as part of the MySQL Enterprise subscription.
For more details about MySQL Enterprise Backup, see Section 29.2, “MySQL Enterprise Backup Overview”.
You can move an
InnoDB database simply by copying
all the relevant files listed under "Cold Backups" in
Section 14.18.1, “InnoDB Backup”.
InnoDB data and log files are binary-compatible
on all platforms having the same floating-point number format. If
the floating-point formats differ but you have not used
DOUBLE data types in your tables,
then the procedure is the same: simply copy the relevant files.
When you move or copy file-per-table
files, the database directory name must be the same on the source
and destination systems. The table definition stored in the
InnoDB shared tablespace includes the database
name. The transaction IDs and log sequence numbers stored in the
tablespace files also differ between databases.
To move an
.ibd file and the associated table
from one database to another, use a
RENAME TABLE db1.tbl_name TO db2.tbl_name;
If you have a “clean” backup of an
.ibd file, you can restore it to the MySQL
installation from which it originated as follows:
The table must not have been dropped or truncated since you copied the
.ibdfile, because doing so changes the table ID stored inside the tablespace.
ALTER TABLEstatement to delete the current
ALTER TABLE tbl_name DISCARD TABLESPACE;
Copy the backup
.ibdfile to the proper database directory.
ALTER TABLEstatement to tell
InnoDBto use the new
.ibdfile for the table:
ALTER TABLE tbl_name IMPORT TABLESPACE;Note
ALTER TABLE ... IMPORT TABLESPACEfeature does not enforce foreign key constraints on imported data.
In this context, a “clean”
file backup is one for which the following requirements are
There are no uncommitted modifications by transactions in the
There are no unmerged insert buffer entries in the
Purge has removed all delete-marked index records from the
mysqld has flushed all modified pages of the
.ibdfile from the buffer pool to the file.
You can make a clean backup
.ibd file using the
Another method for making a clean copy of an
.ibd file is to use the MySQL Enterprise Backup
Use MySQL Enterprise Backup to back up the
Start a second mysqld server on the backup and let it clean up the
.ibdfiles in the backup.
You can use mysqldump to dump your tables on one machine and then import the dump files on the other machine. Using this method, it does not matter whether the formats differ or if your tables contain floating-point data.
One way to increase the performance of this method is to switch off autocommit mode when importing data, assuming that the tablespace has enough space for the big rollback segment that the import transactions generate. Do the commit only after importing a whole table or a segment of a table.