乐趣区

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

问题

已知状况如下:

  1. MySQL 版本为 8.0.21(随 8.0 的小版本升级,MGR 参数和行为变更频繁,须要特地留神版本号)。
  2. MGR 架构,一个节点 C 网络不稳时,与其余节点的通信断开。
  3. 通信断开后,肯定工夫内(5 秒 + group_replication_member_expel_timeout 秒)
    a. 其余节点开始质疑节点 C 可能掉线。在其余节点上,节点 C 的状态为 UNREACHABLE。
    b. 其余节点依然能协商并提交新事务,其协商的信息会保留在音讯缓存中。
  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
    a. 行为:
    当某节点意外离线达到(5 秒 + group_replication_member_expel_timeout 秒)后,MGR 将其踢出集群。

如果节点意外离线工夫较短,MGR 能够主动接续音讯,好像节点从未来到。
b. 长处:
网络等发生意外时,该参数越大,越不须要人工参加,集群可主动复原。
c. 老本:

该参数越大,就须要更多的音讯缓存。

d. 老本:

节点未被踢出集群时,能够从该节点读到过期数据。该参数越大,读到过期数据的概率越大。
  1. group_replication_message_cache_size

a. 长处:该参数越大,可缓存的音讯越多,故障节点复原后主动接续的概率越大,不须要人工参加运维。
b. 老本:耗费内存。

小贴士
大家在抉择 MGR 参数时,倡议从以下几个方向思考,达成均衡:

  1. 对环境不稳固的容忍水平
  2. 自动化水平(是否须要人工参加)
  3. 读过期数据的概率
  4. 物理资源耗费

对于 MySQL 的技术内容,你们还有什么想晓得的吗?连忙留言通知小编吧!

退出移动版