故障轉移后，由於額外的事務，MySQL節點加入組復制失敗

Question

我在kubernetes（k8s）上部署了一個3節點的mysql InnoDB集群。 每個mysql節點都是一個k8s POD。 為了測試可用性，我手動刪除了與（使用命令'docker rm xxxx -f）對應的docker容器mysql主節點。 如預期的那樣，k8s成功地重新創建了容器。 但是，新創建的一個無法加入群集（更具體地說，未能加入組復制）。 它抱怨該成員沒有當前組中的事務。 但是，額外的事務是將SESSION.GTID_NEXT設置為AUTOMATIC的操作。 我不知道為什么它在binlog中並導致重新加入失敗。 有人會給我一些提示或建議嗎？ 非常感謝！

MySQL版本是mysql-community-server-minimal-5.7.20-1。 它是從rpm安裝的。

InnodDB群集是通過采用現有的復制組來創建的。 也就是說，我先創建了復制組，然后創建了集群。

MySQL日志是這樣的：

2018-03-12T08：17：21.208124Z 0 [Note]插件group_replication報告：'new state x_run'2018-03-12T08：17：21.218361Z 0 [ERROR]插件group_replication報告：'該成員具有比這些成員更多的已執行事務在組中。 本地交易：925deea1-75db-4e92-86a9-00259c8d8078：1-50>組交易：925deea1-75db-4e92-86a9-00259c8d8078：1-2'2018-03-12T08：17：21.218433Z 0 [錯誤]插件group_replication報告：“成員包含該組中不存在的交易。 該成員現在將退出該組。” 2018-03-12T08：17：21.218444Z 0 [注意]已報告插件group_replication：'要強制此成員進入組，您可以使用group_replication_allow_local_disjoint_gtids_join選項'2018-03-12T08：17：21.218493Z 3 [注意]已報告插件group_replication ：'將要等待視圖修改'2018-03-12T08：17：21.218546Z 0 [注意]插件group_replication報告：'選舉了一個新的具有地址t-baj3bsrg4cp000a1sp3g-mysql-0.mysql：3306的主數據庫，啟用了沖突檢測直到新的主數據庫應用了所有中繼日志。” 2018-03-12T08：17：21.218597Z 15 [注意]插件group_replication報告：'此服務器正在作為主要成員。 2018-03-12T08：17：21.218634Z 0 [注意]插件group_replication報告：'組成員身份已更改為t-baj3bsrg4cp000a1sp3g-mysql-0.mysql：3306，t-baj3bsrg4cp000a1sp3g-mysql-1.mysql：3306，在視圖15208422427926210 ：3。 2018-03-12T08：17：21.218655Z 0 [注意]插件group_replication報告：'地址為t-baj3bsrg4cp000a1sp3g-mysql-2.mysql：3306的成員已在復制組中在線聲明'2018-03-12T08：17： 21.218825Z 4 [錯誤]報告插件group_replication：'無法更新服務器端的認證結果，thread_id：136'2018-03-12T08：17：21.218838Z 4 [錯誤]報告了插件group_replication：'事件處理時出錯！ 得到錯誤：1'2018-03-12T08：17：21.218849Z 4 [錯誤]插件group_replication報告：'在執行組復制的應用程序過程中執行期間發生致命錯誤。 服務器現在將離開組。” 2018-03-12T08：17：21.218864Z 4 [警告]插件group_replication報告：“跳過離開操作：並發嘗試離開該小組的操作正在進行中。” 2018-03-12T08：17：21.218996Z 7 [注意]讀取通道'group_replication_applier'的中繼日志事件時出錯：從屬SQL線程被殺死

故障節點上顯示的Bin日志事件是：

+ ------------------------------------------- + ----- + ---------------- + ----------- + ------------- + ------ ------------------------------------- + | 日志名稱| 位置| event_type | Server_id | End_log_pos | 信息| + ------------------------------------------- + ----- + ---------------- + ----------- + ------------- + ------ ------------------------------------- + | t-baj3bsrg4cp000a1sp3g-mysql-0-bin.000003 | 4 | Format_desc | 100 | 123 | 服務器版本：5.7.20-log，二進制日志：4 | | t-baj3bsrg4cp000a1sp3g-mysql-0-bin.000003 | 123 | Previous_gtids | 100 | 190 | 925deea1-75db-4e92-86a9-00259c8d8078：1-50 | + ------------------------------------------- + ----- + ---------------- + ----------- + ------------- + ------ ------------------------------------- +

Binlog文件中顯示的925deea1-75db-4e92-86a9-00259c8d8078：1-50的事務：

僅供參考，根據mysql日志，設置group_replication_allow_local_disjoint_gtids_join選項確實對我有用。 但是，請參考選項group_replication_allow_local_disjoint_gtids_join的最新文檔，它將在mysql 5.7.22中刪除。 因此，我必須找出問題的根本原因。 謝謝！

Answer 1

我的建議是重新檢查您的基礎架構，因為您看到自己沒有1筆額外的交易。 如果您查看粘貼的信息

925deea1-75db-4e92-86a9-00259c8d8078:1-50 > 925deea1-75db-4e92-86a9-00259c8d8078:1-2 

1-50與1-2意味着您有48個額外的交易。

另外，當您清除較舊的binlog文件或出現循環時，您正在查看一個新的binlog文件。 在此新文件中，您看到的唯一信息是Previous-GTID信息為925deea1-75db-4e92-86a9-00259c8d8078：1-50，這意味着較舊的binlog文件包含有關這50個事務的信息。

您可以使用以下命令

 SHOW BINARY LOGS;

接着

SHOW BINLOG EVENTS [IN 'log_name']

要獲取有關較舊事件的更多信息，或使用mysqlbinlog實用程序檢查其他文件。