问题
已知情况如下：
3. 通讯断开后，一定时间内（5 秒 + group_replication_member_expel_timeout 秒）
其他节点开始质疑节点 C 可能掉线。在其他节点上，节点 C 的状态为 UNREACHABLE。
其他节点仍然能协商并提交新事务，其协商的信息会保存在消息缓存中。
实验
我们知道 MGR 的消息缓存大小由 group_replication_message_cache_size 参数控，我们在三个节点上都将参数设置为最小值（128M），这样比较容易撑满：
我们还需要将 group_replication_member_expel_timeout 调大，使得之后通讯故障的节点 C 不会被集群踢出。
我们需要知道消息缓存已经用了多少，可以使用下面的命令：
现在我们上一些数据库压力，让 MGR 发送消息，将缓存填满：
看一下填满后的缓存状况：
下面，我们将 mgr-3 节点的网络通讯断开：
在其他节点查询状态，可以看到故障节点被质疑，但没有踢出：
然后观察内存统计，查看缓存的释放量：
等待一段时间，可以看到缓存的释放量已经超过缓存大小，意味着整个缓存的内容已经完全换过一轮：
接下来，我们恢复故障节点的通讯。
通讯恢复后，故障节点应当从其他节点的缓存中，获取故障阶段的消息，但这些消息已经从缓存中被清掉了，我们看看故障节点的 error log：
一些结论
行为：
当某节点意外离线达到（5 秒 + group_replication_member_expel_timeout 秒）后，MGR 将其踢出集群。
如果节点意外离线时间较短，MGR 可以自动接续消息，仿佛节点从未离开。
优点：
网络等发生意外时，该参数越大，越不需要人工参与，集群可自动恢复。
成本：
该参数越大，就需要更多的消息缓存。
成本：
节点未被踢出集群时，可以从该节点读到过期数据。
该参数越大，读到过期数据的概率越大。
优点：该参数越大，可缓存的消息越多，故障节点恢复后自动接续的概率越大，不需要人工参与运维。
成本：消耗内存。
小贴士 大家在选择 MGR 参数时，建议从以下几个方向考虑，达成平衡：
对环境不稳定的容忍程度
自动化程度（是否需要人工参与）
读过期数据的概率
物理资源消耗
