Redis-Sentinel

Redis Sentinel 哨兵部署

环境搭建

操作系统：CentOS8
Redis版本：6.0.8（Redis已经提前安装好了）
Redis安装路径：/redis
Redis配置文件名：redis-6379.conf

IP	HOST	Redis-Port	Sentinel-Port	ROLE
192.168.10.11	redis1	6379	26379	Master
192.168.10.12	redis2	6379	26379	Slave1
192.168.10.13	redis3	6379	26379	Slave2

Redis主从复制配置

1.开放redis的端口

firewall-cmd --zone=public --add-port=6379/tcp --permanent
firewall-cmd --reload

2.修改配置redis.conf配置文件
主库

#redis-6379.conf
bind 0.0.0.0
protected-mode yes
port 6379daemonize yes
logfile /redis/log/redis_6379.log
dbfilename dump_6379.rdb

备库1

#redis-6379.conf
bind 0.0.0.0
protected-mode yes
port 6379
daemonize yes
logfile /redis/log/redis_6379.log
dbfilename dump_6379.rdb
slaveof 192.168.10.11 6379

备库2

#redis-6379.conf
bind 0.0.0.0
protected-mode yes
port 6379daemonize yes
logfile /redis/log/redis_6379.log
dbfilename dump_6379.rdb
slaveof 192.168.10.11 6379

3.以次启动主节点和从节点
redis-server redis-6379.conf

4.主节点查看主从状态是否正常

哨兵节点部署

哨兵节点本质上是特殊的Redis节点。

1.开启sentinel所需端口，这边以26379为sentinel端口

firewall-cmd --zone=public --add-port=26379/tcp --permanent
firewall-cmd --reload

2.参考安装包中sentinel.conf配置文件，创建sentinel.conf配置文件（各个节点都需要配置）

port 26379daemonize yes
pidfile /redis/run/redis-sentinel.pid
logfile /redis/log/redis-sentinel.log
dir /redis/sentinelsentinel monitor mymaster 192.168.10.11 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0

sentinel.conf配置文件参数解释

1）sentinel monitor mymaster 192.168.10.11 6379 2
Sentine监听的maste地址，第一个参数是给master起的名字，第二个参数为master IP，第三个为master端口，第四个为当该master挂了的时候，若想将该master判为失效，在Sentine集群中必须至少2个Sentine同意才行，只要该数量不达标，则就不会发生故障迁移。也就是说只要有2个sentinel认为master下线，就认为该master客观下线，启动failover并选举产生新的master。通常最后一个参数不能多于启动的sentinel实例数。 
这个配置是sentinel需要监控的master/slaver信息，格式为sentinel monitor <mastername> <masterIP> <masterPort> <quorum> 其中<quorum>应该小于集群中slave的个数，当失效的节点数超过了<quorum>,则认为整个体系结构失效 
不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移，并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。  换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。
2）sentinel down-after-milliseconds mymaster 30000
表示master被当前sentinel实例认定为失效的间隔时间。master在多长时间内一直没有给Sentine返回有效信息，则认定该master主观下线。也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。  
如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
3）sentinel parallel-syncs mymaster 2
当在执行故障转移时，设置几个slave同时进行切换master，该值越大，则可能就有越多的slave在切换master时不可用，可以将该值设置为1，即一个一个来，这样在某个slave进行切换master同步数据时，其余的slave还能正常工作，以此保证每次只有一个从服务器处于不能处理命令请求的状态。  
parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。  
如果从服务器被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明）， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求，因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。 
当新master产生时，同时进行"slaveof"到新master并进行"SYNC"的slave个数。 
默认为1,建议保持默认值 
在salve执行salveof与同步时，将会终止客户端请求。 
此值较大，意味着"集群"终止客户端请求的时间总和和较大。 
此值较小,意味着"集群"在故障转移期间，多个salve向客户端提供服务时仍然使用旧数据。
4）sentinel auth-pass mymaster 20180408
设置sentinel连接的master和slave的密码，这个需要和redis.conf文件中设置的密码一样
5）sentinel failover-timeout mymaster 180000
failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failoer失败。 
执行故障迁移超时时间，即在指定时间内没有大多数的sentinel 反馈master下线，该故障迁移计划则失效
6）sentinel config-epoch mymaster 0
选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步。这个数字越小， 完成故障转移所需的时间就越长。
7）sentinel notification-script mymaster /redis/script/notify.sh
当failover时，可以指定一个"通知"脚本用来告知当前集群的情况。脚本被允许执行的最大时间为60秒，如果超时，脚本将会被终止(KILL)
8）sentinel leader-epoch mymaster 0
同时一时间最多0个slave可同时更新配置,建议数字不要太大,以免影响正常对外提供服务。

其中，sentinel monitor mymaster 192.168.10.11 6379 2 配置的含义是：该哨兵节点监控192.168.10.11:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。

3.启动运行sentinel有两种方式

redis-sentinel sentinel.conf
或者
redis-server sentinel.conf --sentinel

4.查看sentinel哨兵信息，使用redis-cli 连接哨兵的端口
redis-cli -p 26379

从上述信息可以看出26379哨兵节点已经在监控mymaster主节点(即192.168.10.11:6379)，并发现了其2个从节点和另外2个哨兵节点。

5.查看之前sentinel.conf哨兵的配置文件

从上述信息可以看出，显示哨兵已经发现了从节点和其他哨兵；带有epoch的参数与配置纪元有关（配置纪元是一个从0开始的计数器，每进行一次领导者哨兵选举，都会+1；领导者哨兵选举是故障转移阶段的一个操作）。

故障转移演示

1.首先，先kill命令杀掉主节点
killall redis-server

2.过了一会你会发现info，status变为sdown

3.查看备库的sentinel日志文件（日志文件监控到master down了）

4.查看从库redis日志（发现主从同步失败）

5.过了一会查看从库redis日志（可以该从库变为了主库，13服务器成为了该库的从库）

6.sentinel info发现master切换至12节点了

从上述可以发现12是被选举为主节点，其他的从库节点重新设置为新的主节点的从节点。

7.查看原从库节点的配置文件，发现配置文件都被改写了

对于主从节点，主要是slaveof配置的变化：新的主节点没有了slaveof配置，其从节点则slaveof新的主节点
对于哨兵节点，除了主从节点信息的变化，纪元(epoch)也会变化，下图中可以看到纪元相关的参数都+1了

8.将原本的主节点上线，查看新主库节点redis日志

从上述信息可以看出，将原来的主节点上线后，它会自动成为新主节点的从节点

总结

哨兵系统的搭建过程，有几点需要注意：
（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。
（2）哨兵节点本质上是redis节点。
（3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。
（4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。
（5）一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条sentinel monitor即可实现。