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

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，当节点重新加入集群的时候，会读取整个relay log文件，并根据gtid应用其中尚未在本节点apply的事务。也就意味着节点在重新加入集群前，需要先读1G左右的文件。
When the MySQL Group Replication plugin starts up, it reads through the entire relay log, applying all transactions until it gets caught up to the current point. These transactions are marked with GTIDs and the server will ignore transactions that have already been applied.

解决这个问题，或者将max_binlog_size调小，或者调整max_relay_log_size参数到一个大于0的较小值。

需要注意的是，当节点已经处理recovering状态的时候，调整参数是没有用的。
Changing the value of max_relay_log_size will have no effect on the cluster node while it is in the RECOVERING state, this settings can only be changed when the node is stopped or in the ONLINE state.

实际操作的时候，我并没有找到是这个原因，但是当我在同一个节点再次进行切换验证的时候，recovering的时间确实少了很多。应该是在上一次加入到本次加入之间生成的relay log量较小。

最后

以上就是积极奇异果为你收集整理的MySQL Group Replication 节点重新加入集群时等待时间过长的全部内容，希望文章能够帮你解决MySQL Group Replication 节点重新加入集群时等待时间过长所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。