說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集合（差集）發送過來，復制就這樣開始了。