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.
GTID support with MySQL Server 5.6 and above
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 theGTID_PURGED
configuration option. Execute this file using the mysql command line after restoring the backup data on a slave server. Optionally, you can uncomment theCHANGE 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 theibbackup_slave_info
file afterward.