In this Document
Goal Solution References
To clone a replication slave from a live master with existing data, extra steps must be taken to ensure that the data is copied as a consistent snapshot, and that the correct GTID status is transferred to the slave.
The requirements to achieve this are described in the manual here, but it does not fully detail the steps from start to finish:
Setting Up Replication Using GTIDsUsing GTIDs for Failover and ScaleoutThis document explains the step-by-step process required to clone a master server while it is live and still receiving transactions, the servers need not be made read only. This process assumes a completely blank slave MySQL server system.
If any of the steps do not behave as expected, please see the Error Log file which may contain useful information. To locate the error log, see Note 1478045.1.
[mysqld] gtid_mode=on log_slave_updates enforce_gtid_consistency log_bin
On the master server check the global variable gtid_executed to ensure that it is not blank and contains a GTID value, the precise value does not matter. If this is still blank, try execute a transaction on the server such as an INSERT and then check again.master> SELECT @@global.gtid_executed; +-------------------------------------------+ | @@global.gtid_executed | +-------------------------------------------+ | 3205efd7-86b0-11e6-9bb1-08002715584a:1-25 | +-------------------------------------------+ 1 row in set (0.00 sec)
On the master server create a data export using mysqldump and the following options, then copy the resulting slave_export.sql to the slave server using SCP or similar.root# mysqldump -u root -p --triggers --routines --events --set-gtid-purged=on --all-databases --single-transaction > /root/slave_export.sql root# scp /root/slave_export.sql root@slave_server:/root/
On the slave server check my.cnf and ensure the following options are set appropriately in the [mysqld] section, if necessary set them and restart the server[mysqld] gtid_mode=on log_slave_updates enforce_gtid_consistency log_bin
On the slave server, ensure replication is not running:slave> STOP SLAVE; Query OK, 0 rows affected (0.02 sec)
On the slave server: if GTIDs have been enabled earlier and the existing value of gtid_executed is not empty, for example:slave> SELECT @@global.gtid_executed; +-------------------------------------------+ | @@global.gtid_executed | +-------------------------------------------+ | 3205efd7-86b0-11e6-9bb1-08002715584a:1-15 | +-------------------------------------------+ 1 row in set (0.00 sec)
you must first execute a RESET MASTER on the slave:slave> RESET MASTER; Query OK, 0 rows affected (0.02 sec) slave> SELECT @@global.gtid_executed; +------------------------+ | @@global.gtid_executed | +------------------------+ | | +------------------------+ 1 row in set (0.00 sec)
It is very important this step is only done on the slave. For more information about this step, see also Note 1933237.1.
On the slave server use the MySQL client to import slave_export.sqlroot# mysql -u root -p -e "source /root/slave_export.sql"
On the slave server check that the global variables gtid_executed and gtid_purged have been set, this is done inside of slave_export.sql because we used the --set-gtid-purged flag with mysqldumpslave> SELECT @@global.gtid_executed, @@global.gtid_purged; +-------------------------------------------+-------------------------------------------+ | @@global.gtid_executed | @@global.gtid_purged | +-------------------------------------------+-------------------------------------------+ | 3205efd7-86b0-11e6-9bb1-08002715584a:1-25 | 3205efd7-86b0-11e6-9bb1-08002715584a:1-25 | +-------------------------------------------+-------------------------------------------+ 1 row in set (0.00 sec)
On the slave server configure replication with the master hostname, port, username and password. We also set the MASTER_AUTO_POSITION option which indicates we wish to use GTIDs. No MASTER_LOG_FILE or MASTER_LOG_POS is required. We then start the slave process.slave> CHANGE MASTER TO MASTER_HOST='master_hostname',MASTER_PORT=3306, MASTER_USER='user', MASTER_PASSWORD='password', MASTER_AUTO_POSITION=1; slave> START SLAVE;
On the slave server check the slave status to ensure that the replication is operating correctly and no errors appear. The server should catch up to any changes made since the export started, in most cases this will happen very quickly, perhaps even before you check the status. You can examine Seconds_Behind_Master to see if the slave server has caught up to all changes yet. Specifically check the results for Slave_IO_Running, Slave_SQL_Running (should both be 'Yes') and that the values of Last_IO_Error and Last_SQL_Error are blank.slave> SHOW SLAVE STATUS\G
Your replication slave is now ready for use.MySQL Server
Oracle Database 11g Release 2 Information Center [1436725.2]
Redirect - 1307334.1 Master Note for ORA-1555 Errors [1338919.2]
Configuring A Slave Server After Restoring From A Full Mysqlbackup When Using GTID Replication [1933237.1]
How to Find the MySQL Error Log ? [1478045.1]
Show More
