Clone a Replication Slave From a Live Master using Global Transaction IDs (GTID) and mysqldump (Doc

Clone a Replication Slave From a Live Master using Global Transaction IDs (GTID) and mysqldump (Doc ID 1589291.1) To BottomTo Bottom

In this Document

  Goal
  Solution
  References

 

APPLIES TO:

MySQL Server - Version 5.6 and later
Information in this document applies to any platform.

GOAL

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 GTIDs
  • Using GTIDs for Failover and Scaleout

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

SOLUTION

  1. On the master 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 

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

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

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

  5. On the slave server, ensure replication is not running:
     

    slave> STOP SLAVE;
    Query OK, 0 rows affected (0.02 sec)

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

  7. On the slave server use the MySQL client to import slave_export.sql
     

    root# mysql -u root -p -e "source /root/slave_export.sql"

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

    slave> 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)

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

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

  11. Your replication slave is now ready for use.

REFERENCES

https://dev.mysql.com/doc/refman/en/mysqldump.html
https://dev.mysql.com/doc/refman/en/mysqldump.html#option_mysqldump_set-gtid-purged
NOTE:1933237.1 - Configuring A Slave Server After Restoring From A Full Mysqlbackup When Using GTID Replication
https://dev.mysql.com/doc/refman/en/replication-gtids-howto.html
https://dev.mysql.com/doc/refman/en/replication-gtids-failover.html
NOTE:1478045.1 - How to Find the MySQL Error Log ?
https://dev.mysql.com/doc/refman/en/replication-options-gtids.html#sysvar_gtid_purged
https://dev.mysql.com/doc/refman/en/replication-options-gtids.html#sysvar_gtid_executed
     
     
 
 

 

 
Open document in new windowPrintable Page
   
   
   
   
   
   
   
   
   
   
     

 
 

Related Products

 

MySQL Server

     
 
 

Information Centers

 
   

Oracle Database 11g Release 2 Information Center [1436725.2]

Redirect - 1307334.1 Master Note for ORA-1555 Errors [1338919.2]

     
 
 

Document References

 
   

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]

     
 
 

Recently Viewed

 
 
 
 
 
 
 
 
 
 

Show More

     

 

你可能感兴趣的:(MySql,mysql)