问题
已知状况如下:
- 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 的技术内容,你们还有什么想晓得的吗?连忙留言通知小编吧!