关于mysql:有事务冲突时节点怎么加入MGR集群

• GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。

[toc]

个别节点可能存在事务抵触，导致无奈退出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=0
SET 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 = 267
COMMIT/*!*/;

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命令：

# 重置master
mysql> RESET MASTER;

# 重置GTID_PURGED
mysql> 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 和 clone_max_network_bandwidth 以防止把内网带宽打满。

3. 小结

本文介绍了当某个MGR节点有事务不统一时，如何找到差别的数据，以及如何进行补救。

如果放心数据不统一的话，也能够间接利用clone性能间接重建Secondary节点，也很不便。

另外，线上生产环境中，最好不要设置 slave-skip-erros，尽管遇到数据抵触、数据不存在等报错时能主动疏忽跳过，但长此以往，可能数据不统一的状况越来越重大，等到某天无可奈何要切换主节点时，就压根不敢切了，那时悔之晚矣。

就这，全文完。

Enjoy GreatSQL 🙂

文章举荐：

面向金融级利用的GreatSQL正式开源
https://mp.weixin.qq.com/s/cI…

Changes in GreatSQL 8.0.25 (2021-8-18)
https://mp.weixin.qq.com/s/qc…

MGR及GreatSQL资源汇总
https://mp.weixin.qq.com/s/qX…

GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6…

在Linux下源码编译装置GreatSQL/MySQL
https://mp.weixin.qq.com/s/WZ…

# 对于 GreatSQL

GreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。

Gitee:

https://gitee.com/GreatSQL/Gr…

GitHub:

https://github.com/GreatSQL/G…

Bilibili：

https://space.bilibili.com/13…

微信&QQ群：

可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群

QQ群：533341697

微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 公布！