網(wǎng)上有很多關(guān)于pos機多卡沖突,有事務(wù)沖突時節(jié)點怎么加入MGR集群的知識，也有很多人為大家解答關(guān)于pos機多卡沖突的問題，今天pos機之家(m.afbey.com)為大家整理了關(guān)于這方面的知識，讓我們一起來看下吧!

本文目錄一覽：

1、pos機多卡沖突

pos機多卡沖突

有事務(wù)沖突時節(jié)點怎么加入MGR集群1. 問題場景描述2. 如何修復(fù)2.1 找出事務(wù)差異點2.2 決定如何處理3. 小結(jié)

個別節(jié)點可能存在事務(wù)沖突，導(dǎo)致無法加入MGR集群，該怎么處理？

1. 問題場景描述

有些時候，可能因為網(wǎng)絡(luò)分區(qū)等異常情況導(dǎo)致節(jié)點意外退出MGR集群，在退出之前可能有些事務(wù)還沒來得及發(fā)送到其他節(jié)點?；蛘呖赡芤驗檎`操作，在這個節(jié)點上意外寫入數(shù)據(jù)。那么這個節(jié)點重加入MGR集群時，就可能會報告類似下面的錯誤：

[ERROR] [MY-011526] ... This member has more executed transactions than those present in the group. Local transactions: xx:1-300917674 > Group transactions: xx:1-300917669[ERROR] [MY-011522] ... The member contains transactions not present in the group. The member will now exit the group.'

這段日志的意思是，本地節(jié)點的事務(wù)GTID為 1-300917674，而欲加入的MGR集群的事務(wù)GTID是 1-300917669，本地節(jié)點多了5個事務(wù)，因此無法正確加入。

2. 如何修復(fù)

遇到這種報錯不要慌，我們一起來看下怎么處理。大致可以分為X步走。

2.1 找出事務(wù)差異點

首先，根據(jù)報錯日志，找出本地節(jié)點相對于MGR集群多出來的或有差異的事務(wù)。在本案中，本地節(jié)點多了5個事務(wù)，利用MySQLbinlog來看這些事務(wù)都涉及到哪些數(shù)據(jù)對象：

# -vvv, 打印更多冗余信息，方便排查# --base64-output=decode-rows，進行base64解碼# --include-gtids=，指定要包含的GTID范圍$ mysqlbinlog -vvv --base64-output=decode-rows --include-gtids="0d432272-bddf-11ec-82a9-d08e7908bcb1:300917669-300917674" mgr03.000003 > diff-trxs.sql

接下來就可以對解析出來的SQL文件進行檢查，判斷影響了哪些數(shù)據(jù)對象，以及具體哪些數(shù)據(jù)。

此時，如果MySQL已經(jīng)設(shè)置了 binlog_rows_query_log_events = ON*（這個選項默認值是 OFF，建議改成開啟），則binlog里還會記錄原始SQL語句，更方便排查了，例如這樣：

SET @@SESSION.GTID_NEXT= '0d432272-bddf-11ec-82a9-d08e7908bcb1:300917669'/*!*/;# at 1412#220419 16:43:37 server id 3308 end_log_pos 1494 CRC32 0xe0bed25b Query thread_id=93 exec_time=0 error_code=0SET TIMESTAMP=1650357817/*!*/;BEGIN/*!*/;# at 1494#220419 16:43:37 server id 3308 end_log_pos 1541 CRC32 0xc3635e5d Rows_query# insert into t1 select 4 <-- 這里是原始SQL語句# at 1541#220419 16:43:37 server id 3308 end_log_pos 1591 CRC32 0x3e190d83 Table_map: `sbtest`.`t1` mapped to number 129# at 1591#220419 16:43:37 server id 3308 end_log_pos 1631 CRC32 0x890bd335 Write_rows: table id 129 flags: STMT_END_F### INSERT INTO `sbtest`.`t1`### SET### @1=4 /* INT meta=0 nullable=0 is_null=0 */# at 1631#220419 16:43:37 server id 3308 end_log_pos 1662 CRC32 0x53c6a05a Xid = 267COMMIT/*!*/;2.2 決定如何處理

現(xiàn)在已經(jīng)知道本地節(jié)點和MGR集群相差了哪些數(shù)據(jù)，就需要進行選擇了，看看是要舍棄這些事務(wù)數(shù)據(jù)，還是人工補差。

如果是選擇舍棄差異的事務(wù)數(shù)據(jù)，則需要在本地節(jié)點對有差異的數(shù)據(jù)進行回滾，原來是INSERT的數(shù)據(jù)改成DELETE，原來是DELETE的數(shù)據(jù)改成INSERT，把新值UPDATE成舊值。也可以利用第三方閃回工具進行恢復(fù)。

完成事務(wù)回滾后，在MGR集群某個節(jié)點執(zhí)行下面的SQL，查看當前的GTID信息：

mysql> show master status\\G*************************** 1. row *************************** File: mgr01.000716 Position: 6561 Binlog_Do_DB: Binlog_Ignore_DB:Executed_Gtid_Set: 277e7e5e-b711-11ec-9928-d08e7908bcb1:1-46399285:47399284,277e807f-b711-11ec-9928-d08e7908bcb1:1-31,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-26442019,aaaaaaaa-bbbb-bbbb-aaaa-aaaaaaaaaaa1:1-1853

復(fù)制上面的GTID信息，在欲重新加入MGR的節(jié)點上執(zhí)行下面的SQL命令：

# 重置mastermysql> RESET MASTER;# 重置GTID_PURGEDmysql> SET GLOBAL GTID_PURGED = '277e7e5e-b711-11ec-9928-d08e7908bcb1:1-46399285:47399284,277e807f-b711-11ec-9928-d08e7908bcb1:1-31,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-26442019,aaaaaaaa-bbbb-bbbb-aaaa-aaaaaaaaaaa1:1-1853';

之后應(yīng)該就可以直接啟動MGR服務(wù)，重新加回MGR集群了。

如果是選擇手動補足差異的事務(wù)數(shù)據(jù)，首先也是參考上面的方法，解析binlog導(dǎo)出相對應(yīng)的事務(wù)，確認要補差的事務(wù)數(shù)據(jù)。然后執(zhí)行類似下面的命令，把本地節(jié)點多出來的事務(wù)應(yīng)用到MGR集群的Primary節(jié)點上，例如下面這樣：

# 解析本地binlog，包含有差異的那部分事務(wù)數(shù)據(jù)# 而后直接利用管道應(yīng)用到MGR集群的Primary節(jié)點上$ mysqlbinlog -vvv --base64-output=decode-rows --include-gtids="0d432272-bddf-11ec-82a9-d08e7908bcb1:300917669-300917674" mgr03.000003 | mysql -hmgr01 -uGreatSQL -pGreatSQL

補差的事務(wù)應(yīng)用完畢后，再檢查兩邊的GTID差異，然后同樣也要執(zhí)行 RESET MASTER 以及修改 GTID_PURGED 的工作，之后再啟動MGR服務(wù)即可。

不過，在補完差異數(shù)據(jù)后，可以直接利用clone重建Secondary實例，再加入MGR集群即可，就不用再手動修改GTID這些麻煩且易錯的操作了。在執(zhí)行clone時，如果數(shù)據(jù)量較大，也要注意設(shè)置選項 clone_max_data_bandwidth="360px",height="auto" />

和 clone_max_network_bandwidth="360px",height="auto" />

以避免把內(nèi)網(wǎng)帶寬打滿。

3. 小結(jié)

本文介紹了當某個MGR節(jié)點有事務(wù)不一致時，如何找到差異的數(shù)據(jù)，以及如何進行補救。

如果擔心數(shù)據(jù)不一致的話，也可以直接利用clone功能直接重建Secondary節(jié)點，也很方便。

另外，線上生產(chǎn)環(huán)境中，最好不要設(shè)置 slave-skip-erros，雖然遇到數(shù)據(jù)沖突、數(shù)據(jù)不存在等報錯時能自動忽略跳過，但久而久之，可能數(shù)據(jù)不一致的情況越來越嚴重，等到某天迫不得已要切換主節(jié)點時，就壓根不敢切了，那時悔之晚矣。

就這，全文完。

Enjoy GreatSQL :)

以上就是關(guān)于pos機多卡沖突,有事務(wù)沖突時節(jié)點怎么加入MGR集群的知識，后面我們會繼續(xù)為大家整理關(guān)于pos機多卡沖突的知識，希望能夠幫助到大家！