Table of Contents
Backup and restore operations are especially important in systems that use MySQL replication to synchronize data across a master server and a set of slave servers. In a replication configuration, MySQL Enterprise Backup helps you to deal with entire system images to set up new slave servers, or to restore a master server in an efficient way that avoids unnecessary work for the slave servers. Having multiple slave servers to choose from gives you more flexibility about where to perform backups. When the binary log is enabled, you have more flexibility about restoring to a point in time, even a time that is later than the last backup.
MySQL Enterprise Backup supports the GTID feature of MySQL 5.6:
The GTID feature is compatible with the CSV tables that the mysqlbackup command uses to log job progress and history.
When a server using the GTID feature is backed up,
mysqlbackup produces a file
gtid_executed.sql as part of the backup
data. This file contains a SQL statement that sets the
GTID_PURGED configuration option. Execute
this file using the mysql command line after
restoring the backup data on a slave server. Optionally, you can
uncomment the CHANGE MASTER command in this
file and add any needed authentication parameters to it, before
running it through mysql.
For servers not using GTIDs, you can use the
--slave-info option as before, then
edit and execute the ibbackup_slave_info
file afterward.
If you use MySQL replication, MySQL Enterprise Backup allows you to set up a slave database without stopping the master, by backing up the master and restoring that backup on a new slave server.
Take the backup, transfer it to the slave server, use
mysqlbackup with the
apply-log option to prepare it, and put the
restored backup and the log files in the right directories for
the new slave.
Edit the my.cnf file of the new slave and
put skip-slave-start and
event_scheduler=off under the
[mysqld] section.
Start the new slave mysqld (version >= 5.1). It prints the latest MySQL binary log position the backup knows of.
… InnoDB: Last MySQL binlog file position 0 128760128, file name ./hundin-bin.006 …
Note that InnoDB only stores the binary log position information to its tablespace at a transaction commit. To make InnoDB aware of the current binary log position, you must run at least one transaction while binary logging is enabled.
Use the CHANGE MASTER SQL command on the
slave to initialize it properly. For example:
CHANGE MASTER TO MASTER_LOG_FILE='hundin-bin.006', MASTER_LOG_POS=128760128;
Set the statuses of any events that were copied from the
master to SLAVESIDE_DISABLED. For example:
mysql> UPDATE mysql.event SET status = 'SLAVESIDE_DISABLED';
Remove the line skip-slave-start and
event_scheduler=off entries you added to
the my.cnf file of the slave in step 2.
Restart the slave server. Replication stars.
To backup a slave database, add the
--slave-info option to your backup
command.
To restore the backup on a slave server, follow the same steps outlined in Section 6.1, “Setting Up a New Replication Slave”.
In a statement-based replication (SBR) setting (see Replication Formats for details), whenever the SQL thread for the slave is stopped (for example, during a slave shutdown that has to occur when you restore a backup to a slave server), all temporary tables that are open then will not get replicated on the slave (see Replication and Temporary Tables for details). That means it is not always safe to backup a slave server in an SBR setting with mysqlbackup if temporary tables might be created on the master, as the temporary tables might be missing from the backup, making it inconsistent. Therefore, only use mysqlbackup with an SBR slave if you know no temporary tables are created on the master.
To fix a corruption problem in a replication master database, you can restore the backup, taking care not to propagate unnecessary SQL operations to the slave servers:
Using the backup of the master database, do the
apply-log operation, shut down the database,
and do the copy-back operation.
Edit the master my.cnf file and comment
out log-bin, so that the slaves do not
receive twice the binary log needed to recover the master.
Replication in the slaves must be stopped temporarily while you pipe the binary log to the master. In the slaves, do:
mysql> STOP SLAVE;
Start the master mysqld on the restored backup:
$ mysqld … InnoDB: Doing recovery: scanned up to log sequence number 0 64300044 InnoDB: Last MySQL binlog file position 05585832, file name ./omnibook-bin.002…
InnoDB prints the binary log file
(./omnibook-bin.002 in this case) and the
position (5585832 in this case) it was able
to recover to.
Pipe the remaining of the binary log files to the restored
backup. For example, if there are two more binary log files,
omnibook-bin.003 and
omnibook-bin.004 that come after
omnibook-bin.002, pipe them all with a
single connection to the server (see
Point-in-Time (Incremental) Recovery Using the Binary Log for more
instructions on using mysqlbinlog):
$ mysqlbinlog --start-position=5585833 /mysqldatadir/omnibook-bin.002 \ /mysqldatadir/omnibook-bin.003 /mysqldatadir/omnibook-bin.004 | mysql
The number of remaining binary log files varies depending on the length of the timespan between the last backup and the time to which you want to bring the database up to date. The longer the timespan, the more remaining binary log files there may be. All the binary log files, containing all the continuous binary log positions in that timespan, are required for a successful restore.
The master database is now recovered. Shut down the master and
edit my.cnf to uncomment
log-bin.
Start the master again.
Start replication in the slaves again:
mysql> START SLAVE;