Redis哨兵TILT模式问题解决方案

斯普信专业组

已于 2024-10-11 17:17:47 修改

阅读量288

点赞数 13

文章标签： redis 云计算云原生缓存

于 2024-10-11 16:46:54 首次发布

本文链接：https://blog.csdn.net/qq_40477248/article/details/142857507

版权

Redis sentinel的TILT影响范围

Redis版本影响范围：5、6、7版本

部署方式为k8s部署，都会受到影响，裸金属部署没有问题

当redis哨兵集群进入TILT模式后，业务无法正常连接到redis集群，无法正常使用redis集群。

TILT 模式：倾斜模式

TILT 模式是一种保护模式，当计算机发生严重的故障或灾难时，系统会进入这种模式，禁止除了监控之外的所有操作。在 Redis Sentinel 的上下文中，由于 Sentinel 的大多数操作依赖于时间同步，因此进入 TILT 模式表明 Sentinel 的时间可能存在问题，这使得 Sentinel 的判断变得不可靠。

在 TILT 模式下，Sentinel 除了发送必要的 PING 和 INFO 命令外，不会主动执行其他任何操作，例如主备倒换、标记主观或客观下线等。尽管如此，Sentinel 仍可以通过接收 INFO 命令和发布订阅连接中的 HELLO 消息包来获取外部信息，并据此更新自身的状态。这一模式将持续 SENTINEL_TILT_PERIOD 时长，默认为 30 秒。在此期间内，我们可以认为 TILT 模式是 Sentinel 的被动模式。

Redis集群影响

当 Sentinel 处于“TILT mode”时，会对 Redis 集群产生以下影响：

可靠性降低：
Sentinel 无法正常监视 Master 和 Slave 节点的健康状况，可能导致故障检测不及时。
故障转移机制失效，Master 节点发生故障时无法自动切换到 Slave 节点，影响集群的高可用性。
性能下降：
Sentinel 进程频繁重启或资源不足可能导致集群整体性能下降。
监控指标异常可能提示系统存在潜在的性能瓶颈。
维护复杂度增加：
Sentinel 进程的异常状态增加了维护的复杂度，需要排查具体原因并采取相应措施。

方案验证

组件使用helm 部署bitnami封装出来的部署有问题，请bitnami开发自行排查！
redis域名和ip什么样的情况下会导致redis集群出现偏移? 已看完redis 源码，如下原因会导致哨兵偏移：
（1）服务器或者容器时间紊乱, 对应条件负数;
（2）哨兵实例慢, 导致eventloop时间间隔长, 超过了2秒, 对应条件delta>2000ms

应急方案

前置条件：
1、若仅仅是哨兵出现问题，主从没问题采用5.1进行恢复
2、若主从已无法切换，采用方案5.2进行恢复
3、若重启过程出现warn警告信息“TCP backlog setting of 511”采用方案5.3进行恢复
4、若以上方案都不能解决此问题，可采用方案5.4进行恢复，且需要业务层代码支持

说明： TILT判断依据为，pod日志会有如下信息： “tilt mode exited” TCP backlog报错，日志会有如下信息：

滚动重启

滚动重启setinel pod节点(最好飘逸到其他node，避免node本身问题影响):

kubectl rollout restart -n <命名空间> <statefulset 或者 deployment>

如 Kubectl get pod -n <命名空间> 查看运行状态，
如图：
在这里插入图片描述

哨兵状态：
在这里插入图片描述

Redis实例集群状态：
在这里插入图片描述

以上为表明正常运行。

手动切换主从

手动恢复master-slaves集群，也即手动执行哨兵故障转移流程：
A)、按部署时的配置，更新redis哨兵节点配置（部署的yaml文件）；

master配置（仅供参考，请以实际为准）如下：
在这里插入图片描述

Slave配置（仅供参考，请以实际为准）如：
在这里插入图片描述

B)、而后，启动master-slaves集群节点，验证集群状态，执行：
命令info replication
如下图：
在这里插入图片描述

C)、临时将业务连接的svc绑定到master节点ip，如下图，假设redis-sentinel-node-0为master服务节点，可按照图示操作；
在这里插入图片描述

修改系统参数

若redis哨兵启动报WARNING：“The TCP backlog setting of 511 cannot be enforced”问题，

编辑容器内 /etc/sysctl.conf添加net.core.somaxconn= 1024,执行sysctl -p验证是否添加成功。

验证时间同步问题

关闭时间同步，同时观察sentinel是否还有“tilt mode exited”

#关闭自动同步时间
timedatectl set-ntp no

发现再无“tilt mode exited”日志产生

重启自动时间同步

#开启自动同步时间
timedatectl set-ntp yes

修改副本数

若以上解决方案失效，请将sentinel的三节点，可以将其中两个的sentinel的replicas由1改为0，
可通过命令：

kubectl scale --replicas=0 deployment sentinel-1 -n paas-middleware，kubectl scale --replicas=0 deployment sentinel-2 -n paas-middleware，(假设deployment的名字为sentinel-1,sentinel-2)保留一个，形成sentinel为单节点，
同时：
将sentinel monitor个数由2改成1，
将sentinel parallel-syncs 由2改成1。

官方参考

titl-mode也是redos的sentinel的保护机制，TITL模式是redis的一种保护模式，计算机发生严重的事情或者灾难的时候，会进入这个模式，禁止除了监控之外的操作，而且因为redis sentinel一般操作都是依赖时间，进入TITL模式则说明他的时间也有可能有问题，那这个sentinel的判断就不可信了。

处于该模式下Sentinel除了发送必要的PING及INFO命令外，不会主动做其他操作，例如主备倒换，标志主观、客观下线等。但可以通过INFO 命令及发布订阅连接的HELLO消息包来获取外界信息并对自身结构进行更新，直到SENTINEL_TILT_PERIOD时长（默认为30s）结束为止，我们可以认为Tilt模式是Sentinel的被动模式。
在这里插入图片描述