Redis服务之高可用组件sentinel详解

　　架构图

　　提示：从上面的架构图可以知道，首先我们必须要有一个主从架构的集群，然后在部署sentinel 来对主从同步集群做监控；

　　redis主从复制集群搭建

　　1、在192.168.0.41/42/43上安装redis，可以使用yum安装，也可以使用编译安装，redis安装请参考https://www.jb51.net/article/79096.htm

　　2、配置192.168.0.41/42/43上的redis监听在非本机127.0.0.1上并配置42/43上的redis从属于192.168.0.41

　　master

　　slave01

　　slave02

　　提示：redis支持在线修改配置，保存配置到配置文件；SLAVEOF 指令用于指定redismaster的ip地址和端口，表示把该redis配置成对应master的slave角色；CONFIG REWRITE是把我们的配置保存到配置文件；

　　在master上查看是否有两个从节点连接到master

　　验证：在master上写数据，看看是否能够及时同步到两个slave上？

　　提示：可以看到在主库上写数据，从库上能够及时的同步主库上的数据；到此redis的主从集群就搭建完毕了；

　　配置sentinel，让其监控master

　　提示：三个sentinel的配置都是一样的，这里需要明确指定监控主从同步集群的master的ip地址和端口，以及有效法定票数，有效法定票数指的是至少有多少个sentinel主观认为master down了，然后才触发选举新master操作；通常在这种流言协议中，一般都是大于集群半数，如果是3台sentinel，至少要2台主观认为master宕机，才开始触发选举新master；如果是5台，那至少要3台；如果master配置的有认证密码，我们还需要在sentinel中指定认证密码；

　　sentinel配置文件说明

　　bind：该指令和redis配置文件中的bind是同样的用法，用于指定sentinel的监听地址；默认不指定，监听本机所有可用地址；

　　protected-mode：指定是否开启保护模式；

　　port：用于指定sentinel的监听端口；默认是26379

　　daemonize：用于指定sentinel是否运行为守护进程，yes表示运行为后台守护进程；no表示不运行为守护进程，直接在前台运行；

　　pidfile：指定pid文件路径；

　　logfile：指定日志文件路径；

　　dir：指定sentinel的工作路径；

　　sentinel monitor master-name> ip> redis-port> quorum>：用于指定监控master节点的ip地址和端口以及有效法定票数；其中master-name>是给监控的master一个名称，可以随便写，起标识的作用；quorum>表示sentinel集群的quorum机制，即至少有quorum个sentinel节点同时判定主节点故障时，才认为其真的故障；

　　sentinel auth-pass master-name> password>：指定master认证密码；通常都需要设置密码，并且master的密码和slave的密码应该是一样；

　　sentinel down-after-milliseconds master-name> milliseconds>：配置监控到指定的集群的主节点异常状态持续多久方才将标记为“故障”；

　　sentinel parallel-syncs master-name> numslaves>：指在failover过程中，能够被sentinel并行配置的从节点的数量；

　　sentinel failover-timeout master-name> milliseconds>：sentinel必须在此指定的时长内完成故障转移操作，否则，将视为故障转移操作失败；

　　sentinel notification-script master-name> script-path>：通知脚本，此脚本被自动传递多个参数；

　　了解了sentinel的配置文件，接下我们把3台sentinel都启动起来

　　master

　　slave01

　　slave02

　　提示：从上面的信息可以看到3个sentinel都监控master的ip地址和端口，其实他们3个的配置文件都是一样的；

　　查看sentinel日志

　　提示：从上面的日志信息可以了解到sentinel监控的master是192.168.0.41：6379；并且有两个slave分别是192.168.0.42：6379和192.168.0.43：6379；

　　查看sentinel状态

　　提示：它提示我们开启了保护模式；

　　关闭保护模式

　　重启sentinel，再次查看sentinel状态

[root@master ~]# systemctl restart redis-sentinel.service
[root@master ~]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port 
LISTEN 0 511 *:26379 *:* 
LISTEN 0 511 *:6379 *:* 
LISTEN 0 128 *:22 *:* 
LISTEN 0 100 127.0.0.1:25 *:* 
LISTEN 0 511 :::26379 :::* 
LISTEN 0 128 :::22 :::* 
LISTEN 0 100 ::1:25 :::* 
[root@master ~]# redis-cli -h 192.168.0.41 -p 26379 
192.168.0.41:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.0.41:6379,slaves=2,sentinels=3
192.168.0.41:26379> info clients
# Clients
connected_clients:3
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
192.168.0.41:26379> CLIENT LIST
id=2 addr=192.168.0.42:59048 fd=14 name=sentinel-f60b324b-cmd age=38 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
id=3 addr=192.168.0.43:37480 fd=15 name=sentinel-eada229c-cmd age=38 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=publish
id=4 addr=192.168.0.41:36706 fd=16 name= age=32 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
192.168.0.41:26379>

　　提示：从上面的状态信息可以看到当前sentinel监控的master是出于正常ok状态，有两个slave和3个sentinel；对于192.168.0.41：26379目前有3个客户端连接，二个是sentinel，一个本机；到此3台sentinel搭建启动完成；

　　验证：把master宕机，看看sentinel是否将在两个从节点选举一个为新master？是否将另外一个slave重新指向新master？

　　在slave01上查看主从同步信息

　　提示：第一次查看只是告诉我们master宕机了，第二次查看就告诉我们当前节点为master，并且拥有一个slave节点，这说明已经完成了故障转移，slave01已经被提升为新的master了；

　　在192.168.0.43上查看主从信息，看看是否指向新的master？

　　提示：在slave02上看主从同步信息，可以看到slave02已经从属新master了；

　　查看故障转移时 sentinel日志

　　提示：从上面的日志信息可以了解到，在从sdown到odown后，就会触发vote算法开始选举leader；然后将原master降级为slave，然后将选举出来的leader原salve属性去除（slaveof no one）;然后提升新master，然后将剩下的slave重新配置新master为主；最后是切换master，开始新的监控；

　　查看故障 转移后的 redis 配置文件

　　提示：故障转移后 redis.conf 中的 slaveof 行的 master IP 会被修改，sentinel.conf 中的 sentinel monitor IP 会被修改。同时在sentinel配置文件的末尾还会有添加known-slave和known-sentinel等信息；

　　修复旧master 让其重新上线

　　提示：把原master启动后，它自动就成为了新主的slave；这主要是因为sentinel在故障转移时把其配置文件中的slaveof 修改成新的master地址了；

　　在新master上查看主从同步信息

　　提示：在没有恢复原master时，在新master上查看主从同步信息，只能看到一个salve，启动原master后，在看就有两个slave是在线；

总结

到此这篇关于Redis服务之高可用组件sentinel的文章就介绍到这了,更多相关Redis服务之高可用组件sentinel内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！