redis哨兵脑裂

现象

查看pod和svc的ip。

k get po,svc -n redis

file

查看server0,master,只有一个slave,地址是10.96.83.150
file
查看server1,slave,master地址是10.96.136.211,salve地址是10.96.46.212
file
查看serevr2,slave,master地址是10.96.83.150,min_slaves_good_slaves:0
file

即server0和serevr2在一个集群里,server1单独一个集群。

查看哨兵日志
redis-master 10.96.136.211。
file
redis-master 10.96.83.150发生了FAILOVER,重新选举,选举了10.96.136.211为master。
file
master是10.96.83.150,然后10.96.83.150reboot了,从10.96.136.211接收配置更新,切换到了10.96.136.211为master。
file

原因

如果当前主库突然出现暂时性 “失联”,而并不是真的发生了故障,此时监听的哨兵会自动启动主从切换机制。当这个原始的主库从假故障中恢复后,又开始处理请求,但是哨兵已经选出了新的主库,这样一来,旧的主库和新主库就会同时存在,这就是脑裂现象。

redis pod启动时间不同,导致了启动时选举异常。

影响

脑裂最直接的影响,就是客户端不知道应该往哪个主节点写入数据,结果就是不同的客户端会往不同的主节点上写入数据。严重的话,脑裂会进一步导致数据丢失。当哨兵恢复对老master节点的感知后,会将其降级为slave节点,然后从新maste同步数据(full resynchronization),导致脑裂期间老master写入的数据丢失。

如何判断数据丢失

数据丢失不一定是发生了脑裂,最常见的原因是主库的数据还没有同步到从库,结果主库发生了故障,等从库升级为主库后,未同步的数据就丢失了。

通过比对主从库上的复制进度差值来进行判断,也就是计算 master_repl_offset 和 slave_repl_offset 的差值。如果从库上的 slave_repl_offset 小于老master的 master_repl_offset,那么,我们就可以认定数据丢失是由数据同步未完成导致的。

而判断是否发生了脑裂,可以采取排查客户端的操作日志的方式。通过看日志能够发现,在主从切换后的一段时间内,会有客户端仍然在和老master通信,并没有和升级的新master进行交互,这就相当于主从集群中同时有了两个master。根据这个迹象,我们就可以判断可能是发生了脑裂。

解决

查看value.yaml

file

这两个配置就是用来解决redis脑裂。

min-slaves-to-write

是指主库最少得有 N 个健康的从库存活才能执行写命令。

这个配置虽然不能保证 N 个从库都一定能接收到主库的写操作,但是能避免当没有足够健康的从库时,主库无法正常写入,以此来避免数据的丢失 ,如果设置为 0 则表示关闭该功能。

min-slaves-max-lag

是指从库和主库进行数据复制时的 ACK 消息延迟的最大时间;超出则拒绝写入。

这两个配置项组合后的要求是,主库连接的从库中至少有 N 个从库,和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒,否则,主库就不会再接收客户端的请求了。

这样一来,即使原主库是假故障,它在假故障期间也无法响应哨兵发出的心跳测试,也不能和从库进行同步,自然也就无法和从库进行 ACK 确认了。原主库就会被限制接收客户端请求,客户端也就不能在原主库中写入新数据,就可以避免脑裂现象的发生了。

file

恢复

删除redis pod,重新同步。
file

0 0 投票数
文章评分
订阅评论
提醒
guest

0 评论
最旧
最新 最多投票
内联反馈
查看所有评论

相关文章

开始在上面输入您的搜索词,然后按回车进行搜索。按ESC取消。

返回顶部
0
希望看到您的想法,请您发表评论x