## 背景 server A,B 為雙主結構，對于 server A 當gtid_next設置為AUTOMATIC時，A上執行的事務在binlog刷盤時遞增獲取事務的gtid，從而保證了在binlog中屬于A的gtid是連續遞增的。 A的binlog在B應用時，B會通過 Executed_Gtid_Set 來記錄A的binlog在B的執行情況。而A的binlog中gtid是連續的，從而 1. B未開啟并行復制，B依次應用binlog，Executed_Gtid_Set中B的gtid集合應該是連續的，如`A:1-100`； 2. B開啟并行復制此時，B并發應用binlog，Executed_Gtid_Set中B的gtid集合末端可能會出現不連續的情況，如`A:1-92:94-96:98-100`， 但是如果在A停止寫入，B和A完全同步的情況下，Executed_Gtid_Set中B的gtid集合應該是連續的。 以下分析均基于雙主結構。 ## GTID不一致產生原因 并行復制 前面提到，并行復制時，Executed_Gtid_Set 尾部可能出現正常的空洞。這種不一致可以忽略，最終會一致的。 change master導致gtid丟失 change master重新指定binlog的拉取位置會導致主備gtid不一致。 考慮如下情況 主庫： ~~~ create table t1(c1 int) engine=innodb; create view v1 as select * from t1; ~~~ 備庫： ~~~ set sql_log_bin=0; drop view v1; ~~~ 主庫： ~~~ create view v1 as select * from t1; ~~~ 執行失敗但仍然會生成binlog, binlog中error_code=1050，參考之前月報[binlog event 中的 error code](http://mysql.taobao.org/monthly/2015/06/05/)。 ~~~ #160118 17:33:11 server id 2219317521 end_log_pos 172885 CRC32 0xb6f4693d Query thread_id=76714 exec_time=0 error_code=1050 SET TIMESTAMP=1453109591/*!*/; CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`127.0.0.1` SQL SECURITY DEFINER VIEW `v1` AS select * from t1 ~~~ 備庫： ~~~ show slave status\G Last_SQL_Error: Query caused different errors on master and slave. Error on master: message (format)='Table '%-.192s' already exists' error code=1050 ; Error on slave: actual message='no error', error code=0\. Default database: 'zy'. Query: 'CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`127.0.0.1` SQL SECURITY DEFINER VIEW `v1` AS select * from t1' ~~~ 備庫create view執行成功，而與預期應出現的binlog error_code不一致導致備庫復制中斷。 那么如何修復此類錯誤呢？首先想到這個binlog事件是可以跳過的，因此嘗試使用跳過空事務的方式來嘗試修復。實際上，這種修復方式是不起作用的。 構造空事務來忽略相同gtid，執行start slave；后SQL線程執行過程如下 1. 首先預檢查gtid是否執行，如果此gtid已執行，語句直接返回成功0; 2. 然后檢查預期error_code是否為1050，而實際error_code=0，還是不一致。 因此，此類錯誤通過構造空事務方式無法修復。 此時就需要change master 方式指向失敗事件的下一個位點。然后按位點的方式(master_auto_position=0)來拉binlog。 ~~~ stop slave; change master to master_log_file='xxxx', master_log_pos=xxx,master_auto_position=0; start slave; ~~~ 至此失敗已經修復，但show slave status可以看到 Executed_Gtid_Set 存在空洞，gtid已經不一致了。 此時，我們可以通過skip空事務的方式來彌補這個空洞。 下一步，我們可以選擇修改為通過gtid方式來拉binlog(此步必須在彌補空洞之后）。 ~~~ stop slave; change master to master_auto_position=1; start slave; ~~~ 主機crash 主庫所在主機crash后，可能導致主庫比備庫少一些gtid。 binlog在寫文件時先write，再sync。假設主庫在write binlog之后，sync 之前，同時備庫也拉取了這些未sync的binlog。此時主庫宕機，主庫一部分 binlog 未落盤，但這部分binlog已經傳到了備庫，那么備庫會比主庫多一些事務。因此主庫重啟后，重新構造 gtid_executed_set 時會比備庫少一些gtid。 那些未sync的事務實際處于兩階段提交的prepare狀態，重啟后這些處于prepare的事務由于沒有寫binlog會回滾掉。 主機宕機HA切換后，新主庫會比新備庫多一些事務。 而實際上新主庫會比新備庫多一些事務應該沒有影響，這些事務是用戶發出了commit命令，但主機crash了，沒有收到commit的回復，處于未知狀態。這些未決事務可以提交也可以回滾！ 對于以上情況，在binlog沒有purge的情況下，結合應用我們可以根據gtid來修復主備不一致的情況，或回滾備庫的修改，或者重做主庫丟失的事務。 ## gtid不一致的 影響 假設備庫比主庫少一些gtid, 而主庫多出來的這些gtid已經purge了。如果用備庫做的備份集來恢復出一個實例時，備庫會去主庫拉取缺少的那些gtid，而那些gtid已經purge了。 這就會導致臭名昭著的1236問題 ~~~ 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.' ~~~ 根據前面的gtid不一致的分析，我們應該提前發現不一致，并及時修復，避免此類情況發生。 ## 修復方法 這里總結些gtid不一致的修復方法： 1. 對于可以忽略的gtid事務，可以通過跳過gtid的方式修復； 2. 修改GTID_PURGED的方式 先reset master，再設置GTID_PURGED來修復不一致，此種方式需確保主備數據一致的情況下進行，風險較大，酌情考慮。