Redis全方位讲解--哨兵模式(Sentinel模式)
前言
当按照上一篇《redis主从复制》部署好之后,我们会想,一旦redis的master出现了宕机,并且我们并没有及时发现,这时候就可能会出现数据丢失或程序无法运行。此时,redis的哨兵模式就派上用场了,可以用它来做redis的高可用。
功能作用
- 监控(monitoring):Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
- 提醒(Notifation):当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
- 自动故障转移(Automatic failover):当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
部署
同样,我们还是将每个哨兵部署在一个单独的容器中。
sentinel配置文件
redis-sentinel1:https://github.com/Johnson19900110/johnsondock/blob/master/redis-sentinel/config/sentinel.conf
redis-sentinel2:https://github.com/Johnson19900110/johnsondock/blob/master/redis-sentinel/config/sentinel-slave1.conf
redis-sentinel3:https://github.com/Johnson19900110/johnsondock/blob/master/redis-sentinel/config/sentinel-slave2.conf
这三个配置文件一模一样,都是监听master的。要不你把这个配置文件copy到容器中,要不你就创建三份,分别挂载到容器中,这里选择了后面一种方法。
这里介绍几个基本的配置
sentinel monitor mymaster redis 6379 2 监听的master的容器别名为redis,端口是6379,最后面的2是当大于等于2个哨兵认为master主观下线后(无论这个值为多少,至少得有一半以上的哨兵判定master主观下线后,master才会被客观下线),master才会被客观下线,这是sentinel重新从slave中选举一个来当master。
sentinel auth-pass mymaster 123456 如果master配置了密码,则此项必须配置,否则sentinel会将master标记问主观下线(sdown)。
docker-composer配置文件
### REDIS-SENTINEL ################################################ # master redis-sentinel: image: johnson19900110/redis-sentinel:latest restart: always #如果master未开启数据持久化,此项应该删除 volumes: - ./redis-sentinel/config/sentinel.conf:/usr/local/etc/redis/redis-sentinel.conf networks: - backend depends_on: - redis # redis sentinel slave 1 redis-sentinel-slave1: image: johnson19900110/redis-sentinel:latest restart: always volumes: - ./redis-sentinel/config/sentinel-slave1.conf:/usr/local/etc/redis/redis-sentinel.conf networks: - backend depends_on: - redis-slave1 - redis-sentinel # redis sentinel slave 2 redis-sentinel-slave2: image: johnson19900110/redis-sentinel:latest restart: always volumes: - ./redis-sentinel/config/sentinel-slave2.conf:/usr/local/etc/redis/redis-sentinel.conf networks: - backend depends_on: - redis-slave2 - redis-sentinel-slave1
启动容器
docker-compose up -d redis-sentinel-slave2
执行以上命令后,就启动了三个哨兵模式的容器
这是我们进入容器,查看是否redis-sentinel是否在工作。
我们可看到,已经与master建立连接,通过status=ok可以知道,master正在正常工作,并且有2个从节点和3个哨兵节点。现在你再打开sentinel的配置文件,会发现发生了改变。
conf文件被重写了,并且哨兵模式会自动检测到master的两个slave和另外两个sentinel。
故障演示
1、使master宕机,只需要关闭master的容器即可。
如果此时再去三个哨兵节点里用info sentinel查看信息。
会发现这时候master节点的address信息变了,这就说明哨兵模式起作用了。但他这里还是显示新的master有两个slave。是因为原master节点宕机了,一旦它重启,sentinel就会把它变成新的master节点的slave节点。我们可以去172.18.0.6这个容器中看下。
可以用以上docker命令查看容器的IP地址。进入容器后,还是在redis-cli下用info replication查看信息。
我们可以看到这个slave变成了新的master,另外一个slave也变成了新master节点的slave。如果你查看redis节点的配置文件,会发现也被重写了。 这是我们再重启原master节点试试(注意:当他重启成功后,就变成了slave节点,所以要打开持久化配置)。
当容器重启成功后,我们再去新的master节点中使用info replication查看下。
正如我们所料,它成为了新的master的slave节点。如果你查看原master的配置文件,会发现多了
最后,因为新的master节点是slave节点升级的,所以他的持久化配置还是存在的,如果你想要关掉它,只需要进入redis-cli,然后执行
至此,一次redis的master节点故障转移就演示完成了。这次演示实现了redis的监控和自动故障转移特性。
提醒特性是使用的订阅功能,需要后端代码开发配合的。
发布与订阅信息
客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器: 你不可以使用 PUBLISH 命令向这个服务器发送信息, 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令, 通过订阅给定的频道来获取相应的事件提醒。
一个频道能够接收和这个频道的名字相同的事件。 比如说, 名为 +sdown 的频道就可以接收所有实例进入主观下线(SDOWN)状态的事件。
通过执行 PSUBSCRIBE * 命令可以接收所有事件信息。
以下列出的是客户端可以通过订阅来获得的频道和信息的格式: 第一个英文单词是频道/事件的名字, 其余的是数据的格式。
注意, 当格式中包含 instance details 字样时, 表示频道所返回的信息中包含了以下用于识别目标实例的内容:
@ 字符之后的内容用于指定主服务器, 这些内容是可选的, 它们仅在 @ 字符之前的内容指定的实例不是主服务器时使用。
- +reset-master :主服务器已被重置。
- +slave :一个新的从服务器已经被 Sentinel 识别并关联。
- +failover-state-reconf-slaves :故障转移状态切换到了 reconf-slaves 状态。
- +failover-detected :另一个 Sentinel 开始了一次故障转移操作,或者一个从服务器转换成了主服务器。
- +slave-reconf-sent :领头(leader)的 Sentinel 向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令,为实例设置新的主服务器。
- +slave-reconf-inprog :实例正在将自己设置为指定主服务器的从服务器,但相应的同步过程仍未完成。
- +slave-reconf-done :从服务器已经成功完成对新主服务器的同步。
- -dup-sentinel :对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候,就会出现这种情况。
- +sentinel :一个监视给定主服务器的新 Sentinel 已经被识别并添加。
- +sdown :给定的实例现在处于主观下线状态。
- -sdown :给定的实例已经不再处于主观下线状态。
- +odown :给定的实例现在处于客观下线状态。
- -odown :给定的实例已经不再处于客观下线状态。
- +new-epoch :当前的纪元(epoch)已经被更新。
- +try-failover :一个新的故障迁移操作正在执行中,等待被大多数 Sentinel 选中(waiting to be elected by the majority)。
- +elected-leader :赢得指定纪元的选举,可以进行故障迁移操作了。
- +failover-state-select-slave :故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
- no-good-slave :Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级,又或者直接放弃执行故障转移操作。
- selected-slave :Sentinel 顺利找到适合进行升级的从服务器。
- failover-state-send-slaveof-noone :Sentinel 正在将指定的从服务器升级为主服务器,等待升级功能完成。
- failover-end-for-timeout :故障转移因为超时而中止,不过最终所有从服务器都会开始复制新的主服务器(slaves will eventually be configured to replicate with the new master anyway)。
- failover-end :故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
- +switch-master :配置变更,主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
- +tilt :进入 tilt 模式。
- -tilt :退出 tilt 模式。