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.
For more information about using MySQL Enterprise Backup with replication, see Chapter 6, Using MySQL Enterprise Backup with Replication.
© 2013, Oracle Corporation and/or its affiliates
User Comments
Add your own comment.