第19问:MGR 架构,如果一个节点网络不稳,消息缓存会被撑满么?

发布时间:2020-08-21 浏览次数:322


问题

已知情况如下:

1. MySQL 版本为 8.0.21(随 8.0 的小版本升级,MGR 参数和行为变更频繁,需要特别注意版本号)。

2. MGR 架构,一个节点 C 网络不稳时,与其他节点的通讯断开。

3. 通讯断开后,一定时间内(5 秒 + group_replication_member_expel_timeout 秒)

  1. 其他节点开始质疑节点 C 可能掉线。在其他节点上,节点 C 的状态为 UNREACHABLE。

  2. 其他节点仍然能协商并提交新事务,其协商的信息会保存在消息缓存中。

4. 通讯恢复后,节点 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 相关的参数:

1. group_replication_member_expel_timeout

  1. 行为:当某节点意外离线达到(5 秒 + group_replication_member_expel_timeout 秒)后,MGR 将其踢出集群。如果节点意外离线时间较短,MGR 可以自动接续消息,仿佛节点从未离开。

  2. 优点:网络等发生意外时,该参数越大,越不需要人工参与,集群可自动恢复。

  3. 成本:该参数越大,就需要更多的消息缓存。

  4. 成本:节点未被踢出集群时,可以从该节点读到过期数据。该参数越大,读到过期数据的概率越大。

2. group_replication_message_cache_size

  1. 优点:该参数越大,可缓存的消息越多,故障节点恢复后自动接续的概率越大,不需要人工参与运维。

  2. 成本:消耗内存。

小贴士

大家在选择 MGR 参数时,建议从以下几个方向考虑,达成平衡:

对环境不稳定的容忍程度

自动化程度(是否需要人工参与)

读过期数据的概率

物理资源消耗




关于爱可生

上海爱可生信息技术股份有限公司是国内开源数据库解决方案领导者、工业互联网高维数据应用创新者。爱可生为产业互联网创新应用提供高性价比、快速落地实现的多数据库管理平台、分布式数据库系统、数据库容器云平台、多地多中心跨云容灾等解决方案。

在工业互联网相关垂直行业,深入分析数据价值,构建数据中台和业务中台的基础软件PaaS平台,用数据技术驱动企业高质量增长。公司产品已被广泛应用于各行业,累计用户超过400家,其中包括工商银行、招商银行、中国人寿、中国太保、国家电网、上汽集团、中国移动、华为等30多家世界500强企业。



点击此处“阅读全文”,了解更多




上一篇: 第02期:ClickHouse单机部署以及从MySQL增量同步数据

下一篇: 第05期:Prometheus 数据查询(一)

咨询客服 在线咨询
400-820-6580 免费电话