python redis 哨兵_Redis Sentinel 哨兵模式

最新推荐文章于 2024-07-23 10:48:41 发布

月末刀戈

最新推荐文章于 2024-07-23 10:48:41 发布

阅读量256

点赞数

文章标签： python redis 哨兵

本文链接：https://blog.csdn.net/weixin_34718952/article/details/112887916

版权

本文介绍了Redis Sentinel哨兵模式的网络架构、配置启动、实现流程、故障转移及节点管理。Sentinel通过监控Master和Slave，自动进行故障转移，确保高可用性。配置包括设置监控、故障判断和主从切换策略。故障转移时，Sentinel会根据优先级和复制进度选择新的Master，并同步更新所有Sentinel节点的配置。

摘要由CSDN通过智能技术生成

Redis Sentinel 哨兵模式

1.网络架构

网络结构如下，通过Sentinel监控Master和Slave服务器：

2.配置启动

配置文件如下：

vi /etc/redis-sentinel.conf

port 26379

dir "/tmp"

logfile "/var/log/redis/sentinel_20086.log"

# 进程守护

daemonize yes

# 格式：sentinel

# 最后的一个2代表在sentinel集群中，多少个节点认为master死了，才能真正认为该master不可用

sentinel monitor T1 127.0.0.1 6379 2

# sentinel会向master发送心跳确认存活

# 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息

# 那么这个sentinel会主观地认为这个master已经不可用了

# (subjectively down, 也简称为SDOWN)。

# down-after-milliseconds 用来指定这个“一定时间范围”，单位是毫秒，默认30秒。

sentinel down-after-milliseconds T1 15000

# failover过期时间。

# 当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failoer失败。

# 默认180秒，即3分钟。

sentinel failover-timeout T1 120000

# 在发生failover时，这个选项指定了最多可以有多少个slave同时对新的master进行同步。

# 这个数字越小，完成failover所需的时间就越长；

# 这个数字越大，就意味着越多的slave因为replication而不可用。

# 可以通过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态。

sentinel parallel-syncs T1 1

# sentinel 连接密码验证

# sentinel auth-pass xxxxx

# 发生切换之后执行的一个自定义脚本

# sentinel notification-script

# sentinel client-reconfig-script

Sentinel 也需要集群化，以确保：

某个/些 Sentinel节点挂了，仍然可以实现Redis主从切换；

Redis客户端可以通过任意一个Sentinel读取/写入信息。

启动Sentinel：

redis-sentinel /path/to/sentinel.conf

启动后，通过Sentinel的自动识别，配置文件中会自动加上已识别的Redis集群节点和Sentinel集群节点。

3.实现流程

Sentinel集群通过配置文件发现master，启动时会监控master；

向master发送info命令，获取其所有slave节点；

Sentinel集群向Redis主从服务器发送hello信息(心跳)，包括Sentinel本身的ip、端口、id等内容，以此来向其他Sentinel宣告自己的存在；

Sentinel集群通过订阅接收其他Sentinel发送的hello信息，以此来发现监视同一个主服务器的其他Sentinel；集群之间会互相创建命令连接用于通信，因为已经有主从服务器作为发送和接收hello信息的中介，Sentinel之间不会创建订阅连接；

Sentinel集群使用ping命令来检测实例的状态，如果在指定的时间内(down-after-milliseconds)没有回复或则返回错误的回复，那么该实例被判为下线；

当failover主备切换被触发后，并不会马上进行，还需要Sentinel中的大多数sentinel授权后才可以进行failover，即进行failover的Sentinel会去获得指定quorum个的Sentinel的授权，成功后进入ODOWN状态。如在5个Sentinel中配置了2个quorum，等到2个Sentinel认为master死了就执行failover。

Sentinel向选为master的slave发送 SLAVEOF NO ONE 命令，选择slave的条件是Sentinel首先会根据slaves的优先级来进行排序，优先级越小排名越靠前。如果优先级相同，则查看复制的下标，哪个从master接收的复制数据多，哪个就靠前。如果优先级和下标都相同，就选择进程ID较小的。

Sentinel被授权后，它将会获得宕掉的master的一份最新配置版本号(config-epoch)，当failover执行结束以后，这个版本号将会被用于最新的配置，通过广播形式通知其它sentinel，其它的sentinel则更新对应master的配置。

注意：

因为redis采用的是异步复制，没有办法避免数据的丢失。

可以在redis.conf通过以下配置来使得数据不会丢失：

// master最少得有多少个健康的slave存活才能执行写命令

min-slaves-to-write 1

// 延迟小于min-slaves-max-lag秒的slave才认为是健康的slave

min-slaves-max-lag 10

当所有Slave都不符合条件时，master将停止写入。

4.故障转移

发生故障转移时，需要进行领导者选举。

sentinel首先会根据slaves的优先级来进行排序，优先级越小排名越靠前；