Take a full backup of the source and then use, for example, thecopy-back-and-apply-logcommand, to restore the backup and the log files to the right directories on the new replica and prepare the data.

Edit themy.cnf文件的the new replica and putskip-slave-startandevent_scheduler=off(if the source uses theEvent Scheduler) under the[mysqld]section.

Start the new replicamysqld. You see the following in the server's output:

… InnoDB: Last MySQL binlog file position 0 128760007, file name ./hundin-bin.000006 …

While aLast MySQL binlog file positionhas been displayed, it is NOT necessarily the latest binary log position on the backed up server, as InnoDB does not store binary log position information for any DDL operations or any changes to non-InnoDB tables.Do not use this binary log position to initialize the replica. The next step explains how to find the correct binary log position to use.

Look for the filedatadir/meta/backup_variables.txtwheredatadiris the data directory of the new replica. Look into the file to retrieve the latest binary log position and the corresponding log file number stored inside:

binlog_position=hundin-bin.000006:128760128

Use theCHANGE MASTER TOSQL statement and the information you have retrieved in the last step to initialize the replica properly:

CHANGE MASTER TO MASTER_LOG_FILE='hundin-bin.000006', MASTER_LOG_POS=128760128;

Set the statuses of any events that were copied from the source toSLAVESIDE_DISABLED. For example:

mysql> UPDATE mysql.event SET status = 'SLAVESIDE_DISABLED';

Remove the lineskip-slave-startandevent_scheduler=offentries you added to themy.cnf文件的the replica in step 2. (You can also leave theskip-slave-startentry in, but then you will always need to use theSTART SLAVEstatement to start replication whenever you restart the replica server.)

Restart the replica server. Replication starts.

Take a full backup of the source and then use, for example, thecopy-back-and-apply-logcommand, to restore the backup and the log files to the right directories on a new GTID-enabled replica and prepare the data.

Edit themy.cnf文件的the new replica and putskip-slave-startandevent_scheduler=off(if the source uses theEvent Scheduler) under the[mysqld]section.

Start the new replica server.

Connect to the replica server with themysqlclient. Then, execute the following statement to reset the binary log:

mysql> RESET MASTER;

And execute the following statement to stop the binary logging:

mysql> SET sql_log_bin=0;

When a server using the GTID feature is backed up,mysqlbackupproduces a file namedbackup_gtid_executed.sql, which can be found in the restored data directory of the new replica server. The file contains a SQL statement that sets theGTID_PURGEDconfiguration option on the replica:

# On a new replica, issue the following command if GTIDs are enabled: SET @@GLOBAL.GTID_PURGED='f65db8e2-0e1a-11e5-a980-080027755380:1-3';

It also contains a commented-outCHANGE MASTER TO初始化复制语句:

# Use the following command if you want to use the GTID handshake protocol: # CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

Uncomment the command and add any needed connection and authentication parameters to it (for example,MASTER_HOST,MASTER_USER,MASTER_PASSWORD, andMASTER_PORT):

# Use the following command if you want to use the GTID handshake protocol: CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_USER='muser', MASTER_PASSWORD='mpass', MASTER_PORT=18675, MASTER_AUTO_POSITION = 1;

Execute the file with themysqlclient

mysql> source /path-to-backup_gtid_executed.sql/backup_gtid_executed.sql

Set the statuses of any events that were copied from the source toSLAVESIDE_DISABLED. For example:

mysql> UPDATE mysql.event SET status = 'SLAVESIDE_DISABLED';

Remove theskip-slave-startandevent_scheduler=offentries you added to themy.cnf文件的the replica in step 2. (You can also leave theskip-slave-startentry in, but then you will always need to use theSTART SLAVEstatement to start replication whenever you restart the replica server.)

Restart the replica server. Replication starts.