冲突检测数据库太大得问题，导致事务提交慢

performance_schema.replication_group_member_stats表中  COUNT_TRANSACTIONS_ROWS_VALIDATING 列 含义。
参考文献来看，描述是:  可用于认证但尚未进行垃圾收集的事务行数。

因此，数据库将保持增长，直到垃圾收集开始(稍后会更多)。


数据库用于验证是否可以在组/集群的所有成员上提交事务。这是通过包含由给定GTID更新的表和行的主键的信息来实现的。这种组合存储在冲突检测数据库中。冲突解决数据库的大小是受冲突解决影响的主键的数量——这也就是 COUNT_TRANSACTIONS_ROWS_VALIDATING 。

在两次垃圾收集之间，冲突解决数据库的大小自然会增长。每次提交事务时都会发生这种增长。

垃圾收集将每60秒从冲突解决中清除一次事务。一旦满足以下条件，就可以从冲突解决数据库中删除GTID:

事务已在所有组成员上提交
冲突解决数据库中不存在在该事务之前提交的其他事务
所以你应该能看到 COUNT_TRANSACTIONS_ROWS_VALIDATING  增长，每分钟减少一次(不一定减少到零)。

建议：
1、检查是否存在没有主键的表
2、有没有长时间没有提交的事务

升级到GreatSQL就对了，专门针对这个问题做了优化，可以参见这个PPT里的内容

https://gitee.com/GreatSQL/Great ... %8A%BF%E5%8A%9B.pdf

chongzh 发表于 2023-10-26 17:06
performance_schema.replication_group_member_stats表中  COUNT_TRANSACTIONS_ROWS_VALIDATING 列 含义。 ...

都有主键，我遵循得mgr要求，对每个表都做了主键。另外，不存在长时间不提交得事务。正常情况下，我观察1分钟左右一般会减半，比如2万，清理后就变成1万左右。但是并发大起来了，或者cpu忙不过来时，这个清理不及时，导致这个数值很大，而事务提交时又会去对比这个冲突库，数值很大，导致遍历时长就长了，导致提交很慢。我看网易温正湖大佬提到他们做的库将这个1分钟调为了10秒，（他也提到了代码中得参数broadcast_gtid_executed_period，这个定死得60秒，但是我不敢改，怕出问题，毕竟还玩不转源码）而且用参数可控，但是他们好像没开源。都是云上。所以咨询下greatsql有这方面得优化没，我了解到greatsql有一个快速单主模式，不知道有没有缓解这个。

yejr 发表于 2023-10-26 18:02
升级到GreatSQL就对了，专门针对这个问题做了优化，可以参见这个PPT里的内容

https://gitee.com/GreatSQL/ ...

好的，感谢，看到了。“优化事务认证队列清理算法，规避每60s抖动问题。”请问清理间隔改成多少了呢。能通过在官方得mgr中加入greatsql的节点，来一步一步替换官方的节点么？

yejr 发表于 2023-10-26 18:02
升级到GreatSQL就对了，专门针对这个问题做了优化，可以参见这个PPT里的内容

https://gitee.com/GreatSQL/ ...

叶大师，再请教一个问题呢，我在用官方mgr时，事务大小限制为100M，一个事务100M。并发多个事务就导致内网带宽（千兆）直接跑满，导致mgr节点之间通信故障，数据库不可用。请问，这个怎么避免呢，greatsql有对应优化么。能把节点心跳数据给独立出来用其他网卡不

running_db 发表于 2023-10-26 18:12
好的，感谢，看到了。“优化事务认证队列清理算法，规避每60s抖动问题。”请问清理间隔改成多少了呢。能 ...

MySQL是每60s清理一次，当遇到大队列时就悲剧了
GreatSQL大概是每秒清理，且优化认证队列数据结构

running_db 发表于 2023-10-26 18:16
叶大师，再请教一个问题呢，我在用官方mgr时，事务大小限制为100M，一个事务100M。并发多个事务就导致内 ...

你这是用的哪个版本？8.0以上的话，可以设置消息分片（试试调低 group_replication_communication_max_message_size）。
不过跑MGR时，如果有高并发事务，尤其是有大事务，内网千兆网络是不太够，还是得升级底层基础设施。