GTID複製典型的複製錯誤有兩種:1,數據對象級別的錯誤,包括主庫上update的數據在從庫上不存在,主從逐漸衝突,庫表索引等對象的衝突等等, 如果是純粹的跳過錯誤的話,這一類的錯誤需要跳過思路是找到主庫binlog中對應的事務Id然後在從庫上跳過即可。2,日誌找不到的錯誤,也即從庫在執行利用主庫上 ...
GTID複製典型的複製錯誤有兩種:
1,數據對象級別的錯誤,包括主庫上update的數據在從庫上不存在,主從逐漸衝突,庫表索引等對象的衝突等等,
如果是純粹的跳過錯誤的話,這一類的錯誤需要跳過思路是找到主庫binlog中對應的事務Id然後在從庫上跳過即可。
2,日誌找不到的錯誤,也即從庫在執行利用主庫上的binlog執行對應的事務的時候,因為主庫上日誌被刪除,找不到對應的日誌的錯誤
這一類的錯誤,根據主庫的gtid_purged,更新從庫的gtid_purged,也就是告訴從庫,直接跳過主庫中被刪除的日誌。
本文說的是第一種錯誤。
背景:安裝完master之後,修改root密碼的時候忘了關閉binlog,導致update mysql.user表的時候記錄了binlog
開啟GTID的複製後,直接報錯:
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
網上有非常多的跳過GTID複製報錯的文章,
當然GTID複製報錯的原因有兩種:
一種是數據不一致引起的(主庫事物在從庫上找不到對應數據,或者是數據主鍵衝突,索引衝突之類的)
另一種是主庫上事物日誌被清理,從庫找不到主庫的要重放的事物日誌引起的(Got fatal error 1236 from master when reading data from binary log:)
顯然這裡是因為數據不一致引起的錯誤,最主要的是如何找到引起複制錯誤的事物號,然後跳過這個事物?
之前註意過這個細節問題,這次果然又遇到了。
如何找到造成複製錯誤對應的事物Id?
對於slave status中的信息,註意如下兩行
Retrieved_Gtid_Set: 6d257f5b-5e6b-11e8-b668-5254003de1b6:1-547
Executed_Gtid_Set:
Retrieved_Gtid_Set是slave接收到的事務的信息,
Executed_Gtid_Set是slave已經執行的slave的信息,這裡沒有任何信息,意味著複製的時候從庫遇到主庫的第一個事物Id就發生了錯誤
也就是說第一個事務複製就不能執行,為什麼第一個事務就無法正常複製,按道理,跳過 6d257f5b-5e6b-11e8-b668-5254003de1b6:1就可以的。
從複製報錯來看,如下,說的是:Can't find record in 'user' ****
Last_Errno: 1032 Last_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 744 Skip_Counter: 0
Exec_Master_Log_Pos: 154
然後使用mysqlbinlog 解析主庫上的binlog信息
如下是執行mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS binlog.000002 的結果
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安裝之後,第一時間修改了root的密碼,那麼修改root密碼應該是第一個事務,
因此到了slave上,第一個事務就是無法執行的,為什麼系統表(mysql.user)不允許複製事務?這一點先拋開,
如何在binlog中確認是哪一個事務Id?
上面說的是 Exec_Master_Log_Pos: 154,end_log_pos 744,也就是在這個偏移量之間的事務是導致slave無法複製的,這個事務Id正式1,也即GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
這裡涉及利用Exec_Master_Log_Pos和end_log_pos 找事物Id的問題,從名字大概能猜到是這兩個偏移量之間的一個事物Id
這兩個偏移量之間的事物Id,也就是 '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
筆者一開始是找end_log_pos 744後面的事物Id,也即事物2,然後在從庫設置跳過,怎麼也不行。
對於數據衝突之列的複製錯誤,至於跳過事物Id本身,就不複雜了。
(1)停止slave進程
mysql> STOP SLAVE;
(2)設置事務號,事務號從Retrieved_Gtid_Set獲取
在session里設置gtid_next,即跳過這個GTID
mysql> SET GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
(3)設置空事物
mysql> BEGIN; COMMIT;
(4)恢復事物號
mysql> SET SESSION GTID_NEXT = AUTOMATIC;
(5)啟動slave進程
mysql> START SLAVE;
跳過一個事務之後,重啟slave,恢復正常
稍等幾秒鐘,從庫很快就追上主庫了
學而不思則罔,思而不學則殆。更多的時候是需要大膽去嘗試,去折騰,在慢慢回味其中的道理,掌握了理論,動手試一遍,就大概清楚了。
對於跳過MySQL主從複製的一些總結:
經常遇到不同的複製錯誤,通過show slave status的結果,通常是看是slave_io_running和slave_sql_running來判斷slave複製是否正常。
之前總是糾結slave_io_running為NO的時候,怎麼怎麼辦,slave_sql_running為NO的時候怎麼怎麼辦,
然後上網查出來各種攻略或者解決辦法,答案可謂是五花八門,運氣好一下子就解決了,運氣不好,怎麼也解決不了,類似的問題還會出現。
如果結合原理,不管是哪種複製方式,其實根本不用上網上查各種五花八門的解決辦法,自己認真分析一下,原因大概就猜個差不多了。
1,對於slave_io_running為NO的情況:
首先要想,slave_io_running線程是幹嘛的?連接至master 往slave機器上拉master機器上的binlog的啊,那麼,如果當slave_io_running為NO的時候,原因是什麼?
肯定是slave連不上master了,slave連不上master原因又是什麼呢?
無外乎用戶複製的賬號許可權不足、slave與master之間的網路不通、change master的時候密碼寫錯了、埠號寫錯了等等原因都有可能,
需要自己有目標地去排查,而不是上來就上網搜,一種一種辦法嘗試,別人的問題可能有別人的原因,嘗試用別人的辦法解決自己的問題,不一定總是湊效的。
2,對於slave_sql_running為NO的情況:
首先要想,slave_sql_running線程是幹嘛的?是解析slave_io_running下載過來的master上的binlog的,
如果slave_io_running為YSE,slave_sql_running為NO,也就是說binlog傳輸過來了,解析過程出錯了
哪又是什麼原因?也無外乎是master上的日誌無法應用到slave上,
此時分為兩種情況,舉個例子,如下截圖,last_error 中也寫的很清楚了,err_key_not_found
那就是說說在應用master上一個事物的binlog的時候,slave找不到對應的數據,至於解決辦法先不說,最主要的是找到真正的原因。,
3,最後猜測一種情況:
初始化複製的時候,會不會出現slave_io_running為NO,slave_sql_running為YSE的情況?
我想是不會的,slave_io_running是下載(傳輸)master的binlog的,slave_sql_running是解析下載過來binlog的,怎麼可能會出現master的binlog都沒有下載過來,slave能夠正常解析binlog呢?
上述錯誤是主從複製的第一種錯誤,意思說應用某一條事物的時候出現了錯誤
另一種是主庫上binlog日誌被清理(比如過期自動情況等等),
從庫在執行主庫的事物Id的時候找不到master上的binlog(對應的錯誤信息是Got fatal error 1236 from master when reading data from binary log:)
兩種錯誤,是兩種不同的解決辦法,雖然說都是跳過錯誤日誌,但是跳跟跳還是不太一樣的
gtid跳過複製錯誤的方法:
對於第一種錯誤,說明從庫在應用當前事物Id的時候出錯了,從庫上無法應用某一個事物編號,數據要跳過一個錯誤,正常操作如下:
stop slave; set gtid_next='6d257f5b-5e6b-11e8-b668-5254003de1b6:n'; begin; commit; set gtid_next='AUTOMATIC'; start slave;
對於master上的binlog被清理,slave上找不到對應的binlog,需要跳過主庫上所有被清理的binlog,
在主庫執行show variables like '%gtid_purged%',看主庫清理的日誌的範圍,比如:6d257f5b-5e6b-11e8-b668-5254003de1b6:1-699578
那麼就要跳過主庫上被清理的binlog的範圍,需要設置從庫上的gtid_purged的範圍即可
stop slave; reset master; set global gtid_purged='6d257f5b-5e6b-11e8-b668-5254003de1b6:1-699578'; start slave;
有上述兩種處理方式來看,不同的錯誤需要不同的處理方式,如果弄清楚了背後的原理,其實,問題並不難解決。
所有的問題,都需要具體分析其原因,然後找到其解決方案,這其中,都依賴於事物背後的原理,因此說,學習某種技術,要首選弄清楚其背後的原理,才是根本。