MySQL Group Replication 节点重新加入集群时等待时间过长

最新推荐文章于 2023-09-07 11:04:30 发布

技术菜逼

最新推荐文章于 2023-09-07 11:04:30 发布

阅读量819

点赞数

分类专栏： mysql 文章标签：组复制 recovering 时间长 mysql

本文链接：https://blog.csdn.net/w1346561235/article/details/109518312

版权

在MySQL 5.7.29 el7的组复制环境中，当节点因网络故障被移除并尝试重新加入集群时，发现节点长时间处于recovering状态。排除了事务应用、网络和恢复速度慢等问题后，发现原因是max_relay_log_size参数。当该参数设置大于0，且relay log达到此大小时会自动rotate。未设置时，它依赖于max_binlog_size，可能导致节点重新加入前需读取大体积的relay log。解决办法是调整max_relay_log_size或max_binlog_size，但必须在节点停止或在线状态下进行。在后续的切换测试中，恢复时间显著减少，验证了解决方案的有效性。

摘要由CSDN通过智能技术生成

Mysql 5.7.29 el7 版本，组复制有三个节点，搭建了innodb cluster。做故障切换测试，拔掉其中一个节点的网线，使节点因为网络原因被Expelled。切换成功后使用stop group_replication;start group_replication; 重新加入集群。当然也可以通过mysqlshell操作rejoinInstance。期间节点长时间处于recovering状态，查询performance_schema.replication_group_member_stats,COUNT_TRANSACTIONS_IN_QUEUE列，等待check的事务不到10个；COUNT_TRANSACTIONS_CHECKED=0，没有需要应用的事务；COUNT_TRANSACTIONS_ROWS_VALIDATING=0，用于check的队列也是空的；并且观察到TRANSACTIONS_COMMITTED_ALL_MEMBERS一直没有变化；slave_parallel_workers=32；节点均处于局域网内；因为是切换测试，所以节点并没有离开集群很久，因此也没有大量事务等待应用。节点长时间处于recovering状态，约莫有个2、3分钟的样子才重新online。

综合上述条件，排除了节点restore、事务应用慢、以及网络问题，最终翻到了oracle 文档，确认了应该是max_relay_log_size参数的问题。当max_relay_log_size设置为大于0的值，则当relay log日志文件达到这个设定大小的时候，就会自动的rotate。如果没设置的话，这个值取决于max_binlog_size的大小，本例中的max_binlog_size设置为1G大小，也就是最坏情况下，relay log会增长到1G，当节点重新