标签：Slave Auto Positioning Master 11e9 master 节点 GTID
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集合发送过来，复制就这样开始了。
标签：Slave,Auto,Positioning,Master,11e9,master,节点,GTID 来源： https://blog.51cto.com/coveringindex/2426189
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。