利用GTID模式快速改变主从复制关系

利用GTID模式快速改变主从复制关系

 

在日常数据库运维中，经常需要调整复制的拓扑关系。
master A：192.168.136.137
slave  B：192.168.136.138
slave  C：192.168.136.139
在维护过程中需要将从节点C的复制源修改为B，即将复制拓扑修改为级联关系：A->B->C ,

• #1停止C实例的复制

mysql>sltop slave;

• #2调整C实例的复制关系，修改复制源为B节点，master_auto_position设置为1

mysql>change master to master_host='192.168.136.138',master_user='backup',master_password='123',master_auto_position = 1;

• #3启动C节点的复制

mysql>start slavev;

• #4观察复制情况:

show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.136.138
                  Master_User: backup
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 2171
               Relay_Log_File: localhost-relay-bin.000003
                Relay_Log_Pos: 454
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 2171
              Relay_Log_Space: 2895
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 138
                  Master_UUID: 807de6b3-c4d3-11e7-954f-000c29b46750
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 807de6b3-c4d3-11e7-954f-000c29b46750:1-8
            Executed_Gtid_Set: 807de6b3-c4d3-11e7-954f-000c29b46750:1-8,
d915aee5-d6bd-11e7-ac78-000c29491195:1
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

在start slave操作之后，C节点与B节点之间的交互过程如下。

• 在C节点向B节点发起一个Dump binlog请求，并将自身已经执行的GTID集合信息一起发送到B节点。
• B节点通过对比接收到C节点发送过来的GTID集合，将C节点未执行过的Binlog信息发送给C节点。
• C节点获取到未执行的binlog信息，然后应用这些binlog信息。在这个过程中，B节点也会不断地发送最新的数据库修改信息（binlog）,给C节点。
• C节点不断应用这些binlog信息，最终实现C节点与B节点同步。

基于GTID复制，DBA可以在线快速调整复制的拓扑关心，只需要调整复制节点的基本信息，不需要手动寻找复制节点，方便DBA在线维护。