共计 1328 个字符，预计需要花费 4 分钟才能阅读完成。
问题
已知状况如下：
- MySQL 版本为 8.0.21（随 8.0 的小版本升级，MGR 参数和行为变更频繁，须要特地留神版本号）。
- MGR 架构，一个节点 C 网络不稳时，与其余节点的通信断开。
- 通信断开后，肯定工夫内（5 秒 + group_replication_member_expel_timeout 秒）
a. 其余节点开始质疑节点 C 可能掉线。在其余节点上，节点 C 的状态为 UNREACHABLE。
b. 其余节点依然能协商并提交新事务，其协商的信息会保留在音讯缓存中。 - 通信复原后，节点 C 会从其余节点的音讯缓存中获取漏掉的信息，并跟上进度。那么，音讯缓存会被撑满么？撑满当前会造成什么影响？
试验
咱们先建三节点的 MGR，此处疏忽步骤，大家依照官网文档进行就行。来看一下三节点的状态：
咱们晓得 MGR 的音讯缓存大小由 group_replication_message_cache_size 参数控，咱们在三个节点上都将参数设置为最小值（128M），这样比拟容易撑满：
咱们还须要将 group_replication_member_expel_timeout 调大，使得之后通信故障的节点 C 不会被集群踢出。
咱们须要晓得音讯缓存曾经用了多少，能够应用上面的命令：
当初咱们上一些数据库压力，让 MGR 发送音讯，将缓存填满：
看一下填满后的缓存情况：
上面，咱们将 mgr-3 节点的网络通讯断开：
在其余节点查问状态，能够看到故障节点被质疑，但没有踢出：
同时，咱们能够看到数据库压力依然在持续进行。当初，在 primary 节点上，咱们将内存统计表重置：
而后察看内存统计，查看缓存的开释量：
期待一段时间，能够看到缓存的开释量曾经超过缓存大小，意味着整个缓存的内容曾经齐全换过一轮：
接下来，咱们复原故障节点的通信。
通信复原后，故障节点该当从其余节点的缓存中，获取故障阶段的音讯，但这些音讯曾经从缓存中被清掉了，咱们看看故障节点的 error log：
能够看到，故障节点因为无奈接上音讯，报错退出集群。而后因为 auto-rejoin 机制，故障节点尝试重新加入集群，并通过 binlog 接续数据。
一些论断
本文波及到两个 MGR 相干的参数：
- group_replication_member_expel_timeout
a. 行为：
当某节点意外离线达到（5 秒 + group_replication_member_expel_timeout 秒）后，MGR 将其踢出集群。
如果节点意外离线工夫较短，MGR 能够主动接续音讯，好像节点从未来到。
b. 长处：
网络等发生意外时，该参数越大，越不须要人工参加，集群可主动复原。
c. 老本：
该参数越大，就须要更多的音讯缓存。d. 老本：
节点未被踢出集群时，能够从该节点读到过期数据。该参数越大，读到过期数据的概率越大。- group_replication_message_cache_size
a. 长处：该参数越大，可缓存的音讯越多，故障节点复原后主动接续的概率越大，不须要人工参加运维。
b. 老本：耗费内存。
小贴士
大家在抉择 MGR 参数时，倡议从以下几个方向思考，达成均衡：
- 对环境不稳固的容忍水平
- 自动化水平（是否须要人工参加）
- 读过期数据的概率
- 物理资源耗费
对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！
