MySQL部分5.6版本罕見(jiàn)復(fù)制報(bào)錯(cuò)ERROR 1837如何處理

這篇文章主要介紹了MySQL部分5.6版本罕見(jiàn)復(fù)制報(bào)錯(cuò)ERROR 1837如何處理，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

場(chǎng)景：
    1、簡(jiǎn)單的一主一從，版本MySQL-5.6.20
    2、master_auto_position=0
    3、開(kāi)啟gtid

報(bào)錯(cuò)如下：

   Last_SQL_Errno: 1837
   Last_SQL_Error: Error 'When @@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT variable manual page for detailed explanation. Current @@SESSION.GTID_NEXT is 'c44bd915-440d-11e6-8ea0-6c92bf24b8c0:71844624'.' on query. Default database: '$db'. Query: 'DELETE FROM `db2`.`tb2`'

看完報(bào)錯(cuò)一臉懵逼，莫非主庫(kù)在做什么騷操作？
檢查一下主庫(kù)binlog對(duì)應(yīng)的GTID點(diǎn)，可以發(fā)現(xiàn)點(diǎn)什么：


（已做數(shù)據(jù)脫敏，如上兩張表分別用db1.tb1和db2.tb2來(lái)區(qū)分）

發(fā)現(xiàn)到GTID為【c44bd915-440d-11e6-8ea0-6c92bf24b8c0:71844624】和【71844625】之間做了如下操作：

1. USE db3;
   

2. DELETE FROM `db1`.`tb1`;
   

3. DELETE FROM `db2`.`tb2`;

DELETE FROM `db_1`.`t1`與DELETE FROM `db_2`.`t2`之間并沒(méi)有更多的：SET @@SESSION.GTID_NEXT。
這似乎就違反了GTID的限制，一個(gè)事務(wù)應(yīng)該對(duì)應(yīng)一個(gè)GTID號(hào)才對(duì)。

結(jié)合報(bào)錯(cuò)信息，懷疑此時(shí)在執(zhí)行到第二個(gè)DELETE時(shí)，因?yàn)榈诙€(gè)DELETE沒(méi)有對(duì)應(yīng)的GTID_NEXT，就報(bào)錯(cuò)了：

1. Last_SQL_Errno: 1837 …… Default database: '$db'. Query: 'DELETE FROM `db2`.`tb2`'

再檢查一下存儲(chǔ)引擎，發(fā)現(xiàn)db1.tb1和db2.tb2這兩張表均為memory，即為非事務(wù)引擎。
可能與這個(gè)有關(guān)。


此處，為了修復(fù)這個(gè)復(fù)制故障，在從庫(kù)上做如下操作：

1. 〇 SET SESSION sql_log_bin=0;
   

2. 〇 手動(dòng)執(zhí)行未執(zhí)行的事務(wù)，此處為：DELETE FROM `db2`.`tb2`;
   

3. 〇 SET SESSION sql_log_bin=1;
   

4. 〇 STOP SLAVE sql_thread; SET @@SESSION.GTID_NEXT= 'AUTOMATIC'; START SLAVE sql_thread;

至于為什么在ENFORCE_GTID_CONSISTENCY為ON的情況下，產(chǎn)生這樣違反GTID的events，我搜了一下bug庫(kù)：
更多討論如下：
https://bugs.mysql.com/bug.php?id=71695

該問(wèn)題發(fā)生在5.6.20及以前的5.6版本。
并在5.6.21以后的版本修復(fù)了這個(gè)問(wèn)題。

在文檔中找到：

1.    Replication: When mysqlbinlog processed multiple binary log files into a single output file, this file was not in a useful

2.    state for point-in-time recovery, when it failed with the error, When @@SESSION.GTID_NEXT is set to a GTID, you must

3.    explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT variable manual page for 

4.    detailed explanation. Current @@SESSION.GTID_NEXT is 'xyz'. When mysqlbinlog processes a binary log containing GTIDs, 

5.    it outputs SET gtid_next statements, but gtid_next is set to undefined whenever a commit occurs; this left gtid_next 

6.    undefined when the server had finished processing the output from mysqlbinlog. When the next binary log file started 

7.    with one or more anonymous statements or transactions, the combination of gtid_next being left undefined at the end 

8.    of the first binary log and the second binary log containing anonymous transactions to the error described previously 

9.    (Error 1837, ER_GTID_NEXT_TYPE_UNDEFINED_GROUP).
   

10. 
    

11.    To fix this issue, now, whenever mysqlbinlog encounters this situation, it inserts SET gtid_next = AUTOMATIC 

12.    if required to avoid leaving the previous binary log with gtid_next undefined.
    

13. 
    

14.    In addition, as a result of this fix, mysqlbinlog no longer outputs session variable information for every binary log; 

15.    now, this value is printed only once unless it changes. (Bug #18258933, Bug #71695)

大致原因是：
當(dāng)mysqlbinlog處理包含GTID的binlog時(shí)，它會(huì)輸出gtid_next，但是當(dāng)提交時(shí)，gtid_next會(huì)被設(shè)置為“undefined”。
當(dāng)服務(wù)器處理完來(lái)自mysqlbinlog的輸出后，就留下了binlog undefined。


簡(jiǎn)單的來(lái)說(shuō)：
因?yàn)間tid_next可能會(huì)被設(shè)置為undefined，導(dǎo)致復(fù)制出現(xiàn)1837。
為了修復(fù)這個(gè)問(wèn)題，在MySQL5.6.21版本中，做出了如下修復(fù)：
每當(dāng)mysqlbinlog遇到這種情況，會(huì)自動(dòng)加入如下語(yǔ)句：

1. “SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;”

以避免使用gtid_next保留之前binlog undefined。
（這個(gè)可以在開(kāi)啟GTID時(shí)，輕易測(cè)試得出）


后來(lái)又搜了一下，在使用INSERT DELAYED語(yǔ)法時(shí)，也可能出現(xiàn)這個(gè)問(wèn)題
雖然文檔描述好像和這個(gè)case不太像，但總之也是有收獲的：
〇 升級(jí)到更高版本的MySQL。
〇 盡量使用事務(wù)引擎，避免在一個(gè)事務(wù)中同時(shí)操作事務(wù)表和非事務(wù)表的可能性。
（雖然enforce_gtid_consistency開(kāi)啟，但也有可能出現(xiàn)突破GTID限制的語(yǔ)句，盡量從業(yè)務(wù)上限制）
〇 盡量避免使用INSERT DELAYED語(yǔ)法。

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“MySQL部分5.6版本罕見(jiàn)復(fù)制報(bào)錯(cuò)ERROR 1837如何處理”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!