说GTID-Auto-Positioning

GTID-based的复制,在初始化阶段,Slave节点会把已接收到的和提交的GTID集合信息,发送给Master节点。该GTID集合等价于后面两个GTID集合的并集,@@GLOBAL.gtid_executed + performance_schema.replication_connection_status.RECEIVED_TRANSACTION_SET。

创新互联坚持“要么做到,要么别承诺”的工作理念,服务领域包括:成都网站制作、网站设计、外贸网站建设、企业官网、英文网站、手机端网站、网站推广等服务,满足客户于互联网时代的东港网站设计、移动媒体设计的需求,帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴!

Master节点通过对比Slave节点发送过来的GTID集合信息,然后把所有记录在现存二进制日志文件中的,没有在Slave节点上执行过的GTID集合,发送给Slave节点。

那么,Master节点是如何对比Slave节点发送过来的GTID集合信息的呢?

Master节点会按照自己有的UUID为准,将GTID集合分类,分别计算同类GTID集合的差集。此环节,若Master节点发现Slave节点发送过来的GTID集合中UUID的种类,比自身上UUID的种类多,Master节点会忽略该情况,复制逻辑还会继续进行。

实际例子如下,此情况复制是正常的。

Master节点上GTID集合信息:

[root@MySQL.sock][db1]> show master status\G

*************************** 1. row ***************************

             File: bin.000002

         Position: 796

     Binlog_Do_DB: 

 Binlog_Ignore_DB: 

Executed_Gtid_Set: 0c34233d-b2e1-11e9-85cf-080027f22add:1-2,

4fdc13e1-b59e-11e9-b5e0-080027f22add:1-2

1 row in set (0.01 sec)

Slave节点上GTID集合信息:

[root@mysql.sock][lg]> show master status\G

*************************** 1. row ***************************

             File: bin.000004

         Position: 832

     Binlog_Do_DB: 

 Binlog_Ignore_DB: 

Executed_Gtid_Set: 32a0c858-b59f-11e9-b069-0800270c3d91:1-2,

447e96e1-b59f-11e9-95fe-0800270c3d91:1-2,

b8282f18-b59e-11e9-83b0-0800270c3d91:1-5

1 row in set (0.00 sec)

建立复制关系后,Slave节点上集合信息:

[root@mysql.sock][lg]> show master status \G

*************************** 1. row ***************************

             File: bin.000004

         Position: 1763

     Binlog_Do_DB: 

 Binlog_Ignore_DB: 

Executed_Gtid_Set: 0c34233d-b2e1-11e9-85cf-080027f22add:1-2,

32a0c858-b59f-11e9-b069-0800270c3d91:1-2,

447e96e1-b59f-11e9-95fe-0800270c3d91:1-2,

4fdc13e1-b59e-11e9-b5e0-080027f22add:1-2,

b8282f18-b59e-11e9-83b0-0800270c3d91:1-5

1 row in set (0.00 sec)

又若Master节点发现Slave节点上相同UUID对应的GTID,比自身上的GTID多,这时Master节点会发送ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER报错给Slave节点。

实际例子报错如下:

Last_IO_Errno: 1236(MySQL error code 1236 (ER_MASTER_FATAL_ERROR_READING_BINLOG): Got fatal error %d from master when reading data from binary log: '%-.320s')

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replica'

Last_SQL_Errno: 0

或Master节点发现计算出来相同UUID的GTID集合的差集中,有GTID已被删除了,这时Master节点会发送ER_MASTER_HAS_PURGED_REQUIRED_GTIDS报错给Slave节点。

实际例子报错如下:

Last_IO_Errno: 1236

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

Last_SQL_Errno: 0

经过上面的逻辑后,Master节点最终得以将Slave节点需要的GTID集合(差集)发送过来,复制就这样开始了。


网页名称:说GTID-Auto-Positioning
标题URL:http://pwwzsj.com/article/pcipde.html