網上有很多關于pos機多卡沖突,有事務沖突時節點怎么加入MGR集群的知識，也有很多人為大家解答關于pos機多卡沖突的問題，今天pos機之家(www.tonybus.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!
本文目錄一覽：
1、pos機多卡沖突
pos機多卡沖突
有事務沖突時節點怎么加入MGR集群1. 問題場景描述2. 如何修復2.1 找出事務差異點2.2 決定如何處理3. 小結個別節點可能存在事務沖突，導致無法加入MGR集群，該怎么處理？
1. 問題場景描述有些時候，可能因為網絡分區等異常情況導致節點意外退出MGR集群，在退出之前可能有些事務還沒來得及發送到其他節點。或者可能因為誤操作，在這個節點上意外寫入數據。那么這個節點重加入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.'
這段日志的意思是，本地節點的事務GTID為 1-300917674，而欲加入的MGR集群的事務GTID是 1-300917669，本地節點多了5個事務，因此無法正確加入。
2. 如何修復遇到這種報錯不要慌，我們一起來看下怎么處理。大致可以分為X步走。
2.1 找出事務差異點首先，根據報錯日志，找出本地節點相對于MGR集群多出來的或有差異的事務。在本案中，本地節點多了5個事務，利用MySQLbinlog來看這些事務都涉及到哪些數據對象：
# -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文件進行檢查，判斷影響了哪些數據對象，以及具體哪些數據。
此時，如果MySQL已經設置了 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 決定如何處理
現在已經知道本地節點和MGR集群相差了哪些數據，就需要進行選擇了，看看是要舍棄這些事務數據，還是人工補差。
如果是選擇舍棄差異的事務數據，則需要在本地節點對有差異的數據進行回滾，原來是INSERT的數據改成DELETE，原來是DELETE的數據改成INSERT，把新值UPDATE成舊值。也可以利用第三方閃回工具進行恢復。
完成事務回滾后，在MGR集群某個節點執行下面的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
復制上面的GTID信息，在欲重新加入MGR的節點上執行下面的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';
之后應該就可以直接啟動MGR服務，重新加回MGR集群了。
如果是選擇手動補足差異的事務數據，首先也是參考上面的方法，解析binlog導出相對應的事務，確認要補差的事務數據。然后執行類似下面的命令，把本地節點多出來的事務應用到MGR集群的Primary節點上，例如下面這樣：
# 解析本地binlog，包含有差異的那部分事務數據# 而后直接利用管道應用到MGR集群的Primary節點上$ mysqlbinlog -vvv --base64-output=decode-rows --include-gtids="0d432272-bddf-11ec-82a9-d08e7908bcb1:300917669-300917674" mgr03.000003 | mysql -hmgr01 -uGreatSQL -pGreatSQL
補差的事務應用完畢后，再檢查兩邊的GTID差異，然后同樣也要執行 RESET MASTER 以及修改 GTID_PURGED 的工作，之后再啟動MGR服務即可。
不過，在補完差異數據后，可以直接利用clone重建Secondary實例，再加入MGR集群即可，就不用再手動修改GTID這些麻煩且易錯的操作了。在執行clone時，如果數據量較大，也要注意設置選項 clone_max_data_bandwidth="360px",height="auto" />
和 clone_max_network_bandwidth="360px",height="auto" /> 以避免把內網帶寬打滿。3. 小結本文介紹了當某個MGR節點有事務不一致時，如何找到差異的數據，以及如何進行補救。
如果擔心數據不一致的話，也可以直接利用clone功能直接重建Secondary節點，也很方便。
另外，線上生產環境中，最好不要設置 slave-skip-erros，雖然遇到數據沖突、數據不存在等報錯時能自動忽略跳過，但久而久之，可能數據不一致的情況越來越嚴重，等到某天迫不得已要切換主節點時，就壓根不敢切了，那時悔之晚矣。
就這，全文完。
Enjoy GreatSQL :)
以上就是關于pos機多卡沖突,有事務沖突時節點怎么加入MGR集群的知識，后面我們會繼續為大家整理關于pos機多卡沖突的知識，希望能夠幫助到大家！
