Is there any equivalent of mysqlhotcopy for InnoDB?

Question

Currently I'm using mysqldump to make backups which is slow, but OKish. The big problem is restoring database, which takes a few days. The dump is around 7GB gzipped, so it's not a tiny database, but it shouldn't be outside the range of reasonable with mysql.

So what are my other options? Something like mysqlhotcopy would be perfect.

Solution 1

Take a look at Percona's Xtrabackup, which allows hot backups and is totally free.

Solution 2

If you have --innodb_file_per_table enabled than you can move an .ibd file and the associated table from one database to another, use a RENAME TABLE statement:

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:

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 commercial InnoDB Hot Backup tool

Solution 3

There's the InnoDB/Oracle Hot Backup tool, which costs money. I've never used it, but I'd presume it does what it says on the tin.

Personally, I take an LVM snapshot of my InnoDB tables, and backup from the snapshot -- on restore, it looks like a system crash has occured to InnoDB, which goes through it's normal log replay process on startup. I'm fond of the belt and bracers approach to backups, so I combine the regular snapshot-and-rsyncs with less frequent mysqldumps (and sometimes it's handy to have a fairly recent SQL dump hanging around anyway).

Comments

[Oliver Coleman]

I'm far from an expert, just sharing my experience here; apologies for any technical inaccuracies. As Jarod Elliot indicates, this may be a problem with MySQL using a very slow method for recreating the indexes ("Repair by keycache"). We're having the same problem. According to our host the "relevant MySQL variable here is myisam_max_sort_file_size", however they note that it defaults to 2GB which is probably fine for my purposes. They then indicated that the tmp dir used by MySQL on our server only has a size of 500MB, which is the cause of our problem (resulting in use of Repair by keycache"

[A B]

Did you ever track down those variables? I'd be curious to know how to improve this.

[mbaluyos]

you could have mentioned that this is a verbatim copy of the docs.

[snap]

Just an additional note: This works well but might not be suitable in all cases as LVM snapshots have a big performance penalty. Whenever an LVM volume has an active snapshot tied to it, write performance becomes pretty bad.