Chapter 6 Using MySQL Enterprise Backup with Replication

Table of Contents     [+/-]

6.1 Setting Up a New Replication Slave

6.2 Backing up and Restoring a Slave Database

6.3 Restoring a Master Database

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 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.