?

GTID復(fù)制典型的復(fù)制錯(cuò)誤有兩種：
1，數(shù)據(jù)對(duì)象級(jí)別的錯(cuò)誤，包括主庫上update的數(shù)據(jù)在從庫上不存在，主從逐漸沖突，庫表索引等對(duì)象的沖突等等，
　? 如果是純粹的跳過錯(cuò)誤的話，這一類的錯(cuò)誤需要跳過思路是找到主庫binlog中對(duì)應(yīng)的事務(wù)Id然后在從庫上跳過即可。
2，日志找不到的錯(cuò)誤，也即從庫在執(zhí)行利用主庫上的binlog執(zhí)行對(duì)應(yīng)的事務(wù)的時(shí)候，因?yàn)橹鲙焐先罩颈粍h除，找不到對(duì)應(yīng)的日志的錯(cuò)誤
　? 這一類的錯(cuò)誤，根據(jù)主庫的gtid_purged，更新從庫的gtid_purged，也就是告訴從庫，直接跳過主庫中被刪除的日志。

本文說的是第一種錯(cuò)誤。

背景：安裝完master之后，修改root密碼的時(shí)候忘了關(guān)閉binlog，導(dǎo)致update mysql.user表的時(shí)候記錄了binlog?

開啟GTID的復(fù)制后，直接報(bào)錯(cuò)：
Could not execute Update_rows event on table mysql.user; Can't find record in 'user', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000002, end_log_pos 744

網(wǎng)上有非常多的跳過GTID復(fù)制報(bào)錯(cuò)的文章，
當(dāng)然GTID復(fù)制報(bào)錯(cuò)的原因有兩種：
一種是數(shù)據(jù)不一致引起的（主庫事物在從庫上找不到對(duì)應(yīng)數(shù)據(jù)，或者是數(shù)據(jù)主鍵沖突，索引沖突之類的）
另一種是主庫上事物日志被清理，從庫找不到主庫的要重放的事物日志引起的（Got fatal error 1236 from master when reading data from binary log:）
顯然這里是因?yàn)閿?shù)據(jù)不一致引起的錯(cuò)誤，最主要的是如何找到引起復(fù)制錯(cuò)誤的事物號(hào)，然后跳過這個(gè)事物？
之前注意過這個(gè)細(xì)節(jié)問題，這次果然又遇到了。

?

如何找到造成復(fù)制錯(cuò)誤對(duì)應(yīng)的事物Id？

對(duì)于slave status中的信息，注意如下兩行
Retrieved_Gtid_Set: 6d257f5b-5e6b-11e8-b668-5254003de1b6:1-547
Executed_Gtid_Set:
Retrieved_Gtid_Set是slave接收到的事務(wù)的信息，
Executed_Gtid_Set是slave已經(jīng)執(zhí)行的slave的信息，這里沒有任何信息，意味著復(fù)制的時(shí)候從庫遇到主庫的第一個(gè)事物Id就發(fā)生了錯(cuò)誤
也就是說第一個(gè)事務(wù)復(fù)制就不能執(zhí)行，為什么第一個(gè)事務(wù)就無法正常復(fù)制，按道理，跳過 6d257f5b-5e6b-11e8-b668-5254003de1b6:1就可以的。

?

從復(fù)制報(bào)錯(cuò)來看，如下，說的是：Can't find record in 'user' ****

Last_Errno: 1032Last_Error: Could not execute Update_rows event on table mysql.user; Can't find record in 'user', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;inlog.000002, end_log_pos 744Skip_Counter: 0
Exec_Master_Log_Pos: 154

然后使用mysqlbinlog 解析主庫上的binlog信息
如下是執(zhí)行mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS binlog.000002 的結(jié)果

mysql> stop slave; Query OK, 0 rows affected (0.00 sec)mysql> exit Bye [root@tencent01 mysql8000binlog]# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS binlog.000002 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #180523 17:26:57 server id 8000 end_log_pos 123 CRC32 0x7a72d0c2 Start: binlog v 4, server v 5.7.20-log created 180523 17:26:57 at startup ROLLBACK/*!*/; # at 123 #180523 17:26:57 server id 8000 end_log_pos 154 CRC32 0x1e585b38 Previous-GTIDs # [empty] # at 154 #180523 17:27:08 server id 8000 end_log_pos 219 CRC32 0xcf9ed3c3 GTID last_committed=0 sequence_number=1 rbr_only=yes /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; SET @@SESSION.GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'/*!*/; # at 219 #180523 17:27:08 server id 8000 end_log_pos 287 CRC32 0x5ca28a69 Query thread_id=5 exec_time=0 error_code=0 SET TIMESTAMP=1527067628/*!*/; SET @@session.pseudo_thread_id=5/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549152/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8mb4 *//*!*/; SET @@session.character_set_client=45,@@session.collation_connection=45,@@session.collation_server=45/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; BEGIN /*!*/; # at 287 #180523 17:27:08 server id 8000 end_log_pos 459 CRC32 0xf4845b1b Table_map: `mysql`.`user` mapped to number 4 # at 459 #180523 17:27:08 server id 8000 end_log_pos 744 CRC32 0x74306d73 Update_rows: table id 4 flags: STMT_END_F ### UPDATE `mysql`.`user` ### WHERE ### @1='localhost' /* STRING(180) meta=65204 nullable=0 is_null=0 */ ### @2='root' /* STRING(96) meta=65120 nullable=0 is_null=0 */ ### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @4=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @5=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @6=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @7=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @8=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @9=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @10=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @11=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @12=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @13=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @14=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @15=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @16=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @17=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @18=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @19=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @20=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @21=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @22=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @23=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @24=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @25=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @26=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @27=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @28=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @29=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @30=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @31=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @32=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @33='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */ ### @34='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */ ### @35='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */ ### @36=0 /* INT meta=0 nullable=0 is_null=0 */ ### @37=0 /* INT meta=0 nullable=0 is_null=0 */ ### @38=0 /* INT meta=0 nullable=0 is_null=0 */ ### @39=0 /* INT meta=0 nullable=0 is_null=0 */ ### @40='mysql_native_password' /* STRING(192) meta=65216 nullable=0 is_null=0 */ ### @41='' /* BLOB/TEXT meta=2 nullable=1 is_null=0 */ ### @42=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @43=1527067612 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */ ### @44=NULL /* SHORTINT meta=0 nullable=1 is_null=1 */ ### @45=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### SET ### @1='%' /* STRING(180) meta=65204 nullable=0 is_null=0 */ ### @2='root' /* STRING(96) meta=65120 nullable=0 is_null=0 */ ### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @4=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @5=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @6=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @7=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @8=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @9=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @10=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @11=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @12=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @13=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @14=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @15=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @16=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @17=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @18=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @19=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @20=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @21=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @22=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @23=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @24=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @25=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @26=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @27=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @28=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @29=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @30=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @31=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @32=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @33='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */ ### @34='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */ ### @35='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */ ### @36=0 /* INT meta=0 nullable=0 is_null=0 */ ### @37=0 /* INT meta=0 nullable=0 is_null=0 */ ### @38=0 /* INT meta=0 nullable=0 is_null=0 */ ### @39=0 /* INT meta=0 nullable=0 is_null=0 */ ### @40='mysql_native_password' /* STRING(192) meta=65216 nullable=0 is_null=0 */ ### @41='*81F5E21E35407D884A6CD4A731AEBFB6AF209E1B' /* BLOB/TEXT meta=2 nullable=1 is_null=0 */ ### @42=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @43=1527067612 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */ ### @44=NULL /* SHORTINT meta=0 nullable=1 is_null=1 */ ### @45=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ # at 744 #180523 17:27:08 server id 8000 end_log_pos 813 CRC32 0xd3a07e78 Query thread_id=5 exec_time=0 error_code=0 SET TIMESTAMP=1527067628/*!*/; COMMIT /*!*/; # at 813 #180523 17:27:08 server id 8000 end_log_pos 878 CRC32 0x6451705b GTID last_committed=1 sequence_number=2 rbr_only=no SET @@SESSION.GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:2'/*!*/; # at 878 #180523 17:27:08 server id 8000 end_log_pos 965 CRC32 0x7451238c Query thread_id=6 exec_time=0 error_code=0 SET TIMESTAMP=1527067628/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=45/*!*/; SET @@session.time_zone='SYSTEM'/*!*/; flush privileges /*!*/; # at 965 #180523 17:27:08 server id 8000 end_log_pos 988 CRC32 0x108e7f09 Stop SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/; [root@tencent01 mysql8000binlog]#

不難理解，在master安裝之后，第一時(shí)間修改了root的密碼，那么修改root密碼應(yīng)該是第一個(gè)事務(wù)，
因此到了slave上，第一個(gè)事務(wù)就是無法執(zhí)行的，為什么系統(tǒng)表（mysql.user）不允許復(fù)制事務(wù)？這一點(diǎn)先拋開，
如何在binlog中確認(rèn)是哪一個(gè)事務(wù)Id？
上面說的是 Exec_Master_Log_Pos: 154，end_log_pos 744，也就是在這個(gè)偏移量之間的事務(wù)是導(dǎo)致slave無法復(fù)制的，這個(gè)事務(wù)Id正式1，也即GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
這里涉及利用Exec_Master_Log_Pos和end_log_pos 找事物Id的問題，從名字大概能猜到是這兩個(gè)偏移量之間的一個(gè)事物Id
這兩個(gè)偏移量之間的事物Id，也就是 '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
筆者一開始是找end_log_pos 744后面的事物Id，也即事物2，然后在從庫設(shè)置跳過，怎么也不行。

?

對(duì)于數(shù)據(jù)沖突之列的復(fù)制錯(cuò)誤，至于跳過事物Id本身，就不復(fù)雜了。

(1)停止slave進(jìn)程
mysql> STOP SLAVE;
(2)設(shè)置事務(wù)號(hào)，事務(wù)號(hào)從Retrieved_Gtid_Set獲取
在session里設(shè)置gtid_next，即跳過這個(gè)GTID
mysql> SET GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
(3)設(shè)置空事物
mysql> BEGIN; COMMIT;
(4)恢復(fù)事物號(hào)
mysql> SET SESSION GTID_NEXT = AUTOMATIC;
(5)啟動(dòng)slave進(jìn)程
mysql> START SLAVE;
跳過一個(gè)事務(wù)之后，重啟slave，恢復(fù)正常

?稍等幾秒鐘，從庫很快就追上主庫了

學(xué)而不思則罔，思而不學(xué)則殆。更多的時(shí)候是需要大膽去嘗試，去折騰，在慢慢回味其中的道理，掌握了理論，動(dòng)手試一遍，就大概清楚了。

?

?對(duì)于跳過MySQL主從復(fù)制的一些總結(jié)：

經(jīng)常遇到不同的復(fù)制錯(cuò)誤，通過show slave status的結(jié)果，通常是看是slave_io_running和slave_sql_running來判斷slave復(fù)制是否正常。
之前總是糾結(jié)slave_io_running為NO的時(shí)候，怎么怎么辦，slave_sql_running為NO的時(shí)候怎么怎么辦，
然后上網(wǎng)查出來各種攻略或者解決辦法，答案可謂是五花八門，運(yùn)氣好一下子就解決了，運(yùn)氣不好，怎么也解決不了,類似的問題還會(huì)出現(xiàn)。

如果結(jié)合原理，不管是哪種復(fù)制方式，其實(shí)根本不用上網(wǎng)上查各種五花八門的解決辦法，自己認(rèn)真分析一下，原因大概就猜個(gè)差不多了。

1，對(duì)于slave_io_running為NO的情況：
首先要想，slave_io_running線程是干嘛的？連接至master 往slave機(jī)器上拉master機(jī)器上的binlog的啊，那么，如果當(dāng)slave_io_running為NO的時(shí)候，原因是什么？
肯定是slave連不上master了，slave連不上master原因又是什么呢？
無外乎用戶復(fù)制的賬號(hào)權(quán)限不足、slave與master之間的網(wǎng)絡(luò)不通、change master的時(shí)候密碼寫錯(cuò)了、端口號(hào)寫錯(cuò)了等等原因都有可能，
需要自己有目標(biāo)地去排查，而不是上來就上網(wǎng)搜，一種一種辦法嘗試，別人的問題可能有別人的原因，嘗試用別人的辦法解決自己的問題，不一定總是湊效的。

2，對(duì)于slave_sql_running為NO的情況：
首先要想，slave_sql_running線程是干嘛的？是解析slave_io_running下載過來的master上的binlog的，
如果slave_io_running為YSE，slave_sql_running為NO，也就是說binlog傳輸過來了，解析過程出錯(cuò)了
哪又是什么原因？也無外乎是master上的日志無法應(yīng)用到slave上，
此時(shí)分為兩種情況，舉個(gè)例子，如下截圖，last_error 中也寫的很清楚了，err_key_not_found
那就是說說在應(yīng)用master上一個(gè)事物的binlog的時(shí)候，slave找不到對(duì)應(yīng)的數(shù)據(jù)，至于解決辦法先不說，最主要的是找到真正的原因。,

3，最后猜測(cè)一種情況：
初始化復(fù)制的時(shí)候，會(huì)不會(huì)出現(xiàn)slave_io_running為NO，slave_sql_running為YSE的情況？
我想是不會(huì)的，slave_io_running是下載（傳輸）master的binlog的，slave_sql_running是解析下載過來binlog的，怎么可能會(huì)出現(xiàn)master的binlog都沒有下載過來，slave能夠正常解析binlog呢？

上述錯(cuò)誤是主從復(fù)制的第一種錯(cuò)誤，意思說應(yīng)用某一條事物的時(shí)候出現(xiàn)了錯(cuò)誤
另一種是主庫上binlog日志被清理（比如過期自動(dòng)情況等等），
從庫在執(zhí)行主庫的事物Id的時(shí)候找不到master上的binlog（對(duì)應(yīng)的錯(cuò)誤信息是Got fatal error 1236 from master when reading data from binary log:）
兩種錯(cuò)誤，是兩種不同的解決辦法，雖然說都是跳過錯(cuò)誤日志，但是跳跟跳還是不太一樣的
gtid跳過復(fù)制錯(cuò)誤的方法：

對(duì)于第一種錯(cuò)誤，說明從庫在應(yīng)用當(dāng)前事物Id的時(shí)候出錯(cuò)了，從庫上無法應(yīng)用某一個(gè)事物編號(hào)，數(shù)據(jù)要跳過一個(gè)錯(cuò)誤，正常操作如下：

stop slave; set gtid_next='6d257f5b-5e6b-11e8-b668-5254003de1b6:n'; begin; commit; set gtid_next='AUTOMATIC'; start slave;

對(duì)于master上的binlog被清理，slave上找不到對(duì)應(yīng)的binlog，需要跳過主庫上所有被清理的binlog，
在主庫執(zhí)行show variables like '%gtid_purged%'，看主庫清理的日志的范圍，比如：6d257f5b-5e6b-11e8-b668-5254003de1b6:1-699578
那么就要跳過主庫上被清理的binlog的范圍，需要設(shè)置從庫上的gtid_purged的范圍即可

stop slave; reset master; set global gtid_purged='6d257f5b-5e6b-11e8-b668-5254003de1b6:1-699578'; start slave;

有上述兩種處理方式來看，不同的錯(cuò)誤需要不同的處理方式，如果弄清楚了背后的原理，其實(shí)，問題并不難解決。

所有的問題，都需要具體分析其原因，然后找到其解決方案，這其中，都依賴于事物背后的原理，因此說，學(xué)習(xí)某種技術(shù)，要首選弄清楚其背后的原理，才是根本。

?

總結(jié)

以上是生活随笔為你收集整理的MySQL GTID复制Slave跳过错误事务Id以及复制排错问题总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。