您好,登錄后才能下訂單哦!
GTID-based的復制,在初始化階段,Slave節(jié)點會把已接收到的和提交的GTID集合信息,發(fā)送給Master節(jié)點。該GTID集合等價于后面兩個GTID集合的并集,@@GLOBAL.gtid_executed + performance_schema.replication_connection_status.RECEIVED_TRANSACTION_SET。
Master節(jié)點通過對比Slave節(jié)點發(fā)送過來的GTID集合信息,然后把所有記錄在現(xiàn)存二進制日志文件中的,沒有在Slave節(jié)點上執(zhí)行過的GTID集合,發(fā)送給Slave節(jié)點。
那么,Master節(jié)點是如何對比Slave節(jié)點發(fā)送過來的GTID集合信息的呢?
Master節(jié)點會按照自己有的UUID為準,將GTID集合分類,分別計算同類GTID集合的差集。此環(huán)節(jié),若Master節(jié)點發(fā)現(xiàn)Slave節(jié)點發(fā)送過來的GTID集合中UUID的種類,比自身上UUID的種類多,Master節(jié)點會忽略該情況,復制邏輯還會繼續(xù)進行。
實際例子如下,此情況復制是正常的。
Master節(jié)點上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節(jié)點上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)
建立復制關(guān)系后,Slave節(jié)點上集合信息:
[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節(jié)點發(fā)現(xiàn)Slave節(jié)點上相同UUID對應的GTID,比自身上的GTID多,這時Master節(jié)點會發(fā)送ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER報錯給Slave節(jié)點。
實際例子報錯如下:
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節(jié)點發(fā)現(xiàn)計算出來相同UUID的GTID集合的差集中,有GTID已被刪除了,這時Master節(jié)點會發(fā)送ER_MASTER_HAS_PURGED_REQUIRED_GTIDS報錯給Slave節(jié)點。
實際例子報錯如下:
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
經(jīng)過上面的邏輯后,Master節(jié)點最終得以將Slave節(jié)點需要的GTID集合(差集)發(fā)送過來,復制就這樣開始了。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。