redis高可用之哨兵机制实现主从切换和故障恢复
文章目录
- redis高可用的几种方法
- 哨兵机制
- 架构
- Sentinel工作方式（每个Sentinel实例都执行的定时任务）
- 三个定时任务
- sentinel状态持久化
- redis.conf之save配置项解读
- 哨兵模式具体的实现过程
- 演示故障转移
- 总结
redis高可用的几种方法
Redis实现高可用相关的技术。它们包括：持久化、复制、哨兵和集群，其主要作用和解决的问题是：
持久化 持久化是最简单的高可用方法（有时甚至不被归为高可用的手段），主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
复制 复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
哨兵 在复制的基础上，哨兵实现了自动化的故障恢复。缺陷是写操作无法负载均衡；存储能力受到单机的限制。
集群 通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
哨兵机制
具体请参考官网文档：http://www.redis.cn/documentation.html
哨兵是由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器.
Redis Sentinel，即Redis哨兵，在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。下面是Redis官方文档对于哨兵功能的描述：
监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移（Automatic Failover）：当主节点不能正常工作时，
哨兵会开始自动故障转移操作，它会将失效主节点的其中一
个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
配置提供者（Configuration Provider）：客户端在初始化时，
通过连接哨兵来获得当前Redis服务的主节点地址。
通知（Notification）：哨兵可以将故障转移的结果发送给客户端。
监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。
Redis-cli使用的是Redis提供的底层接口，而客户端则对这些接口、功能进行了封装，以便充分利用哨兵的配置提供者和通知功能。
架构
典型的哨兵架构图如下所示：
它由两部分组成：
哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的Redis节点，不存储数据。
数据节点：主节点和从节点都是数据节点。
Sentinel工作方式（每个Sentinel实例都执行的定时任务）
1）每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个PING命令。
2）如果一个实例（instance）距离最后一次有效回复PING命令的时间超过 own-after-milliseconds 选项所指定的值，则这个实例会被Sentinel标记为主观下线。
3）如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4）当有足够数量的Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线。
5）在一般情况下，每个Sentinel 会以每10秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。
6）当Master被Sentinel标记为客观下线时，Sentinel 向下线的 Master 的所有Slave发送 INFO命令的频率会从10秒一次改为每秒一次。
7）若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被移除。若 Master重新向Sentinel 的PING命令返回有效回复，Master的主观下线状态就会被移除。
主观下线：
所谓主观下线（Subjectively Down， 简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。
主观下线就是说如果服务器在down-after-milliseconds给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复，或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（SDOWN ）。sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master，从服务，其他sentinel）发ping命令，通过判断ping回复是有效回复，还是无效回复来判断实例是否在线（对该sentinel来说是“主观在线”）。
客观下线：
客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断，然后开启failover。
客观下线就是说只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（ODOWN）。
只有当master被认定为客观下线时，才会发生故障迁移。
三个定时任务
sentinel在内部有3个定时任务
1）每10秒每个sentinel会对master和slave执行info命令，这个任务达到两个目的：
a）发现slave节点
b）确认主从关系
2）每2秒每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个发布订阅的频道(sentinel:hello)。
sentinel节点通过__sentinel__:hello频道进行信息交换(对节点的"看法"和自身的信息)，达成共识。
3）每1秒每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。
sentinel状态持久化
snetinel的状态会被持久化地写入sentinel的配置文件中。
每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳。
这意味着，可以安全的停止和重启sentinel进程。
redis.conf之save配置项解读
1) “save 900 1”表示如果900秒内至少1个key发生变化（新增、修改和删除），则重写rdb文件；
2) “save 300 10”表示如果每300秒内至少10个key发生变化（新增、修改和删除），则重写rdb文件；
- “save 60 10000”表示如果每60秒内至少10000个key发生变化（新增、修改和删除），则重写rdb文件。
从下至上去匹配执行
作用
控制什么时候生成rdb文件（快照，也可叫Checkpoint，即检查点）。如果触发任何一个条件，即将内存的数据同步到磁盘
哨兵模式具体的实现过程
实验背景:
server1 主数据库 172.25.2.10
server2 从数据库 172.25.2.11
server3 从代理器 172.25.2.254
关闭3台主机的防火墙和selinux
上一篇文章我已经实现了server1（master）和server2（slave）之间的主从复制,现在将server3也设置为server1的slave节点。
将server1的配置文件发给server3,在serevr3中直接安装就可
开启redis,编辑配置文件
重启redis
测试数据库，读到了serevr1中的数据，却不能写
在serevr1中，配置哨兵机制,哨兵节点本质上是特殊的Redis节点。
在server1上将配置好之后的sentinel.conf文件给两个slave节点各传送一份,注意要在开启sentinel进程之前发送文件，否则文件内容会发生变化
启动serevr1上的哨兵
哨兵节点的启动有两种方式，二者作用是完全相同的：
redis-sentinel sentinel-6379.conf
redis-server sentinel-6379.conf --sentinel
开启serevr2上的哨兵
开启serevr3上的哨兵
按照上述方式配置和启动之后，整个哨兵系统就启动完毕了。可以通过新的ssh连接serevr1，再执行Redis-cli连接哨兵节点进行验证，如下图所示：可以看出6379哨兵节点已经在监控mymaster主节点（即172.25.2.10:26379），并发现了其2个从节点和另外2个哨兵节点。
或者
演示故障转移
哨兵 的作用中配置提供者和通知需要客户端的配合，本文将演示当主节点发生故障时，哨兵的监控和自动故障转移功能。
1.down掉server1的redis服务
查看进程，可以看到server1的redis-server进程已经关闭
但是server1的redis-sentinel进程依然正常运行，可以参加选举
在server2上可以看到将master由server1切换为server2
将serevr1手动恢复为slave
1.编辑redis的配置文件，发现已经恢复为原来的样子
2.再次设置server1作为slave节点，它的master节点是server2
3.重启server1上的redis服务
注意：
这里为什么要我们手动去把server1变为slave，而不是选举完之后直接将master置为slave？
因为server1原来是master，上面会有重要的数据，而且它的slave节点server2和server3上的数据有可能不完全和server1同步,如果这个时候直接将server1置为slave的话，它会以新的master节点作为参考，丢弃原来的所有数据
这时候就有可能造成严重的数据丢失
总结
哨兵系统的搭建过程，有几点需要注意：
-
哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。
-
哨兵节点本质上是Redis节点.
-
每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点.
-
在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写（Config Rewrite）。
本章的例子中，一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条sentinel monitor即可实现。
故障转移分为三个步骤：
1.从下线的主服务的所有从服务里面挑选一个从服务，
将其转成主服务
2.已下线主服务的所有从服务改为复制新的主服务
挑选出新的主服务之后，领头sentinel 向原主服务的从服务发送
slaveof 新主服务 的命令，复制新master。
3.将已下线的主服务设置成新的主服务的从服务，
当其回复正常时，复制新的主服务，变成新的主服务的从服务
当已下线的服务重新上线时，sentinel会向其发送slaveof命令，
让其成为新主的从。
还可以向任意sentinel发生sentinel failover 进行手动故障转移，这样就不需要经过上述主客观和选举的过程。