【redis】sentinel哨兵故障转移与ubuntu虚拟机中配置

sentinel可以被认为是只提供了订阅功能的redis服务器，sentinel之间、sentinel与所有主、从服务器通信都是通过发布/订阅，哨兵之间通过hello频道发现（正在监视相同主服务器的）其他sentinel，记录彼此，通过查询info发现所有主副本信息，向所有主、副本连续广播所有主、副本的配置，同时，所有哨兵都在等待消息，以查看其他哨兵所通告的配置是什么。

sentinel提供了API以检测其状态、主副本运行情况、订阅事件、配置参数（运行时配置即时生效，但单个Sentinel的配置不会自动将更改传播到网络中的其他Sentinel）、进行强行故障转移...

作用

• 监控 sentinel会不断检查您的主实例和副本实例是否按预期工作
• 通知 sentinel可以通过API通知系统管理员或其他计算机程序，其中一个受监视的Redis实例出了问题
• 自动故障转移 如果主服务器未按预期工作，则Sentinel可以启动故障转移过程，在该过程中，将副本升级为主服务器，将其他副本重新配置为使用新的主服务器，并在连接时通知使用redis服务器的应用程序要使用的新地址
• 配置提供程序 Sentinel充当客户端服务发现的授权来源：客户端连接到Sentinels，以询问负责给定服务的当前Redis主服务器的地址。如果发生故障转移，Sentinels将报告新地址

故障转移过程

当某个sentinel监测到master故障（sentinel一段时间内一直不能收到服务器对ping的有效回复，可能是断网或服务器真的故障），会将其标记为主观下线（sdown），一段时间内指定数量（quorum法定人数）的sentinel标记master为sdown并使用sentinel is-master-down-by-addr命令与其他sentinels交换意见后，服务器会被正式下线(odown)，如果一段时间内没达到法定人数的sentinel进行标记sdown，此sdown状态会被移除（这是为了减少网络波动等造成的误报）。

odown状态触发了故障转移后，被选举出的sentinel要获得其他sentinel的授权，获得授权总数达到大多数（同时满足超过一半、大于等于quorum）后就会选出新的master，并在切换主机成功后把新配置和全局唯一的版本号通过发布/订阅通知其他哨兵和从服务器，他们收到新的版本会覆盖掉旧的配置。在被选举出的sentinel执行切换的过程中，其他sentinel不会执行切换，只有一段时间后它没切换成功，其他sentinel会一个一个尝试，这个设定保障了活动性和安全性。

切换新主机后，哨兵不会主动试图重启下线的服务器，手动重启后，哨兵可以识别到它，并把它当做新主机的replica。

odown条件仅适用于master。对于其他类型的实例(从服务器、其他sentinel)，sentinel 在将它们判断为sdown后不需要进行协商，永远不会达到odown。sdown状态的sentinel不再参与投票，sdown状态的replica不再参与选举

选择新主机的依据

• 与主机断开连接的时间   断开连接的时间超过配置的主服务器超时的十倍被认为是不可用的，忽略
• 状态  sdown的副本不参与选举
• 副本优先级  0不参与选举，大于1的数字越小优先级越高
• 复制偏移已处理  优先级相同时，优先选择从master获取更多复制信息的副本
• 运行ID 复制偏移也相同时，选择id较小的

配置

主从

三台虚拟机，ip:10.3.141.75（master）、10.3.141.82(replica)、10.3.141.90(replica)，架构类型：

下载安装redis，可参考官网：

$ sudo add-apt-repository ppa:redislabs/redis
$ sudo apt-get update
$ sudo apt-get install redis

可能会遇到无法获取锁的问题，直接sudo rm 报错的锁

安装后默认无密码运行，在本机运行redis-cli 连接后输入info，可查看所加载配置文件位置，默认在/etc/redis/redis.conf

更改配置：

主机：

bind 0.0.0.0

requirepass 123456

#优先级，当前主机故障时，优先级越小，越优先被选为新主机，设为0表示不参与选举
replica-priority 3

两个从主机都是：

#不限制访问
bind 0.0.0.0

#主机ip、端口
replicaof 10.3.141.75 6379

#主机密码
masterauth 123456

#和主机一致
requirepass 123456

两个从主机只有优先级不一致，分别设为1、2：

#优先级
replica-priority 1

配置完成后，三台redis服务均打开，可连上redis-cli后用info repalication检测主从复制状态。

sentinel

下载安装redis-sentinel

$ sudo apt install redis-sentinel

下载安装完成后，会产生一个/etc/redis/sentinel.conf文件，更改配置（三台主机下的三个文件都是）：

#哨兵使用端口
port 5000

#s1是自己起的主机名,10.3.141.75主机地址，6379是主机redis端口，2是仲裁值，有2个哨兵认为主机下线，主机就被正式下线
sentinel monitor s1 10.3.141.75 6379 2

#5s内没回复，就(单方面地)标记主服务器故障
sentinel down-after-milliseconds s1 5000
sentinel failover-timeout s1 60000
sentinel parallel-syncs s1 1

确保三台redis服务和sentinel端口都是打开状态的前提下，分别启动sentinel服务：

redis-sentinel /etc/redis/sentinel.conf

#或者：
redis-server /etc/redis/sentinel.conf --sentinel

此时已经部署成功了，可以读取到sentinel运行信息。

新打开一个窗口，sudo nano /etc/redis/sentinel.conf，发现每个文件结尾都被追加上了其他redis服务器和sentinel的信息，说明互相识别到了

测试

redis-cli -a 123456 DEBUG sleep 60

此时sentinel可以报告+sdown、+odown、+config-update-from、+switch-master、+slave、-sdown、+convert-to-slave整个过程（+sdown、+odown这些都是sentinel的频道，可以订阅以获取对应信息，或者 psubscribe * 获取全部类型的信息）。

 

相关知识

• 哨兵总数至少大于等于3个，否则单个哨兵的故障对系统影响过大，存在无太大意义。当sentinel sdown数量过多或者sentinel间无法正常通信，会造成无法投票成功，无法故障转移的问题。
• 仲裁值设为大于1/2的哨兵总数时，其对主服务器故障不会太敏感，小于1/2的哨兵总数时意味着对主服务器故障更敏感，在只有少数sentinels不再能够与主服务器通信时，就会标记odown

• 哨兵也是一个redis服务，所以可以通过redis-cli -h 哨兵服务器地址 -p 哨兵端口 -a 哨兵密码（如果有）方式登录，可以通过info等查询对应接口或者订阅其发布频道以获取故障信息

• 哨兵可以配置在单独的客户端，但是应充分考虑到断网的影响

• 一个哨兵可以同时监测多个master，在配置文件中多写几行即可，注意名字不能冲突

• 运行时可以添加新的sentinel，在10s内它就可以被其他sentinel发现并且获取主从配置、其他sentinel的所有信息，如果需要添加多个sentinel可以一个一个来，等它正常运行后添加新的。添加完成后通过查询sentinel master 主服名字确认

• 如果需要一个不需要密码的副本，可以将其优先级为0，不参与选举，以控制安全性

• Sentinel是一个系统，其中每个进程将始终尝试将最后的逻辑配置强加给受监视实例集

网络故障

使用这种网络架构，需要注意到当M1被标记下线，客户端C1被旧的主机分区，此时就算R2已经升为主机，C1还是在向M1写入，当R2启动成功后，这部分数据会被丢弃。

官方推荐开启以下配置，即：当主机监测不到足够数量可供写入的副本时，就停止接受写操作。这种设置会导致当副本全部无法连接，M1无法写入的问题。

min-replicas-to-write 1
min-replicas-max-lag 10

当sentinel之间通信出现问题，或者进入sdown状态的sentinel过多，会导致投票无法进行，sentinel就永远达不成共识，永远无法故障转移。

使用以下两种方式可以避免丢失已确认的写入（不过redis并没有也不打算实现，不过redis商店有类似2的实现）：

1. 使用同步复制（以及适当的共识算法来运行复制状态机）
2. 使用最终一致的系统，在该系统中可以合并同一对象的不同版本

参考：https://redis.io/topics/sentinel