Spec-Zone .ru
спецификации, руководства, описания, API
|
This section explains various techniques for moving or copying some or all InnoDB
tables to a different server. 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 server to development and test an application, or to a data warehouse server to produce reports.
On Windows, 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 my.cnf
or my.ini
file before creating any databases or tables:
[mysqld]lower_case_table_names=1
The MySQL Enterprise Backup product lets you back up a running MySQL database, including InnoDB
and MyISAM
tables, with minimal disruption to operations while producing a
consistent snapshot of the database. When MySQL Enterprise Backup is copying InnoDB
tables, reads and writes to both InnoDB
and MyISAM
tables can continue. During the copying of MyISAM
and other non-InnoDB tables,
reads (but not writes) to those tables are permitted. In addition, MySQL Enterprise Backup can create compressed
backup files, and back up subsets of InnoDB
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
Like MyISAM
data files, InnoDB
data and log files are
binary-compatible on all platforms having the same floating-point number format. You can move an InnoDB
database simply by copying all the relevant files listed in Section 14.2.2.4, "Backing Up and
Recovering an InnoDB
Database". If the floating-point formats differ but
you have not used FLOAT
or DOUBLE
data types in your tables, then the procedure is the same: simply copy
the relevant files.
.ibd
Files When you move or copy .ibd
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
statement:
RENAME TABLEdb1.tbl_name
TOdb2.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 .ibd
file, because doing so changes the table ID stored inside the
tablespace.
Issue this ALTER
TABLE
statement to delete the current .ibd
file:
ALTER TABLE tbl_name
DISCARD TABLESPACE;
Copy the backup .ibd
file to the proper database
directory.
Issue this ALTER
TABLE
statement to tell InnoDB
to use the new .ibd
file for the table:
ALTER TABLE tbl_name
IMPORT TABLESPACE;
In this context, a "clean" .ibd
file backup is one for which the following requirements are satisfied:
There are no uncommitted modifications by transactions in the .ibd
file.
There are no unmerged insert buffer entries in the .ibd
file.
Purge has removed all delete-marked index records from the .ibd
file.
mysqld has flushed all modified pages of the .ibd
file from the buffer pool to the file.
You can make a clean backup .ibd
file using the following method:
Stop all activity from the mysqld server and commit all transactions.
Wait until SHOW
ENGINE INNODB STATUS
shows that there are no active transactions in the database, and the
main thread status of InnoDB
is Waiting for server
activity
. Then you can make a copy of the .ibd
file.
Another method for making a clean copy of an .ibd
file is to use the MySQL
Enterprise Backup product:
Use MySQL Enterprise Backup to back up the InnoDB
installation.
Start a second mysqld server on the backup and let it clean up the
.ibd
files in the backup.
If you use mysqldump to dump your tables on one machine and then import the dump files on the other machine, it does not matter whether the formats differ or your tables contain floating-point data.
One way to increase performance 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.