Redis sentinel哨兵的使用
Redis Sentinel 是 Redis 高可用 的实现方案。Sentinel 是一个管理多个 Redis 实例的工具，它可以实现对 Redis 的 监控、通知、自动故障转移。
1）、Redis 的 主从复制模式 和 Sentinel 高可用架构 的示意图：
2)、Redis Sentinel的主要功能：
Sentinel 的主要功能包括 主节点存活检测、主从运行情况检测、自动故障转移 （failover）、主从切换。Redis 的 Sentinel 最小配置是 一主一从。
Redis 的 Sentinel 系统可以用来管理多个 Redis 服务器，该系统可以执行以下四个任务：
监控 ：Sentinel 会不断的检查 主服务器 和 从服务器 是否正常运行。
通知 ：当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本 向 管理员 或者其他的 应用程序 发送通知。
自动故障转移 : 当 主节点 不能正常工作时，Sentinel 会开始一次 自动的 故障转移操作，它会将与 失效主节点 是 主从关系 的其中一个 从节点 升级为新的 主节点，并且将其他的 从节点 指向 新的主节点。
配置提供者 : 在 Redis Sentinel 模式下，客户端应用 在初始化时连接的是 Sentinel 节点集合，从中获取 主节点 的信息。
3)、主观下线和客观下线
默认情况下，每个 Sentinel 节点会以 每秒一次 的频率对 Redis 节点和 其它 的 Sentinel 节点发送 PING 命令，并通过节点的 回复 来判断节点是否在线。
主观下线：主观下线 适用于所有 主节点 和 从节点。如果在 down-after-milliseconds 毫秒内，Sentinel 没有收到 目标节点 的有效回复，则会判定 该节点 为 主观下线。
客观下线 ：客观下线 只适用于 主节点。如果 主节点 出现故障，Sentinel 节点会通过 sentinel is-master-down-by-addr 命令，向其它 Sentinel 节点询问对该节点的 状态判断。如果超过 <quorum> 个数的节点判定 主节点 不可达，则该 Sentinel 节点会判断 主节点 为 客观下线。
4)、Sentinel的通信命令
Sentinel 节点连接一个 Redis 实例的时候，会创建 cmd 和 pub/sub 两个 连接。Sentinel 通过 cmd 连接给 Redis 发送命令，通过 pub/sub 连接到 Redis 实例上的其他 Sentinel 实例。
Sentinel 与 Sentinel 交互的命令，主要包括：
5)、Redis Sentinel的工作原理
每个 Sentinel 节点都需要 定期执行 以下任务：每个 Sentinel 以 每秒钟 一次的频率，向它所知的 主服务器、从服务器 以及其他 Sentinel 实例 发送一个 PING 命令。
如果一个 实例（instance）距离 最后一次 有效回复 PING 命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel 标记为 主观下线。
如果一个 主服务器 被标记为 主观下线，那么正在 监视 这个 主服务器 的所有 Sentinel 节点，要以 每秒一次 的频率确认 主服务器 的确进入了 主观下线 状态。
如果一个 主服务器 被标记为 主观下线，并且有 足够数量 的 Sentinel（至少要达到 配置文件 指定的数量）在指定的 时间范围 内同意这一判断，那么这个 主服务器 被标记为 客观下线。
在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率，向它已知的所有 主服务器 和 从服务器 发送 INFO 命令。当一个 主服务器 被 Sentinel 标记为 客观下线 时，Sentinel 向 下线主服务器 的所有 从服务器 发送 INFO 命令的频率，会从 10 秒一次改为 每秒一次。
Sentinel 和其他 Sentinel 协商 主节点 的状态，如果 主节点 处于 SDOWN 状态，则投票自动选出新的 主节点。将剩余的 从节点 指向 新的主节点 进行 数据复制。
当没有足够数量的 Sentinel 同意 主服务器 下线时， 主服务器 的 客观下线状态 就会被移除。当 主服务器 重新向 Sentinel 的 PING 命令返回 有效回复 时，主服务器 的 主观下线状态 就会被移除。
注意：一个有效的 PING 回复可以是：+PONG、-LOADING 或者 -MASTERDOWN。如果 服务器 返回除以上三种回复之外的其他回复，又或者在 指定时间 内没有回复 PING 命令， 那么 Sentinel 认为服务器返回的回复 无效（non-valid）。
Redis Sentinel的部署须知:
1、一个稳健的 Redis Sentinel 集群，应该使用至少 三个 Sentinel 实例，并且保证讲这些实例放到 不同的机器 上，甚至不同的 物理区域。
2、Sentinel 无法保证 强一致性。
3、常见的 客户端应用库 都支持 Sentinel。
4、Sentinel 需要通过不断的 测试 和 观察，才能保证高可用。
1、Redis的主从配置分为两篇文章：
第一篇主要介绍了Redis主从配置的搭建过程及使用;
第二篇主要说明各种情况下Redis主从状态，如Master挂掉，Slaver挂掉，挂掉后重新加入等;
2、redis主从说明：
主从的基本概念：Master用于写入，Slaver用于读取，不能写入或修改，一个Master可以对应多个Slaver
Master写入数据后是通过异步复制的方式同步到Slaver，但是基本上不会有延迟
3、Master或Slaver挂掉的情况说明：
1.Slaver挂掉：不影响这个结构，只是该Slaver不能读，但是客户端读写不受影响，重启后即可加入
2.Master挂掉：手动操作，在某个Slaver上执行命令Slaverof no one
| Master挂掉 | 某个Slaver成为Master | 其它Slaver通过Slaverof关联新的Master | 原Master重启 | 原Master关联新的Master | |
| Master | 挂掉 | 状态不变 | 状态为Master | 成为新Master的Slaver | |
| 其它Slaver | 状态不变 | 状态不变 | 成为新Master的Slaver | 新Master的Slaver | 新Master的Slaver |
3.Master挂掉：sentinel哨兵，通过监控Master节点，当其挂掉后，选举其它Slaver成为新的Master
1)、选举出某个Slaver成为新的Master
2)、其它Slaver自动成为新Master的Slaver
3)、原Master重新后自动成为新Master的Slaver
4.添加新的Slaver：使用slaveof host port 到Master节点即可。
4、redis的配置
1、按照1主2从的结构搭建，即1个Master，2个Slaver节点
192.168.142.128 (主) 192.168.142.130 (从) 端口：6310 192.168.142.130 (从) 端口：6311
2、Redis配置文件redis.conf的配置
注意: master设置密码的情况下同步数据,则需要 master的配置文件添加： requirepass 123456 slave的配置文件 添加： masterauth 123456 (只要让slave能连上master就可以了,我们在slave的配置文件中加一句话即可) 192.168.142.128 /usr/local/src/redis-5.0.3/redis_6320.conf bind 192.168.142.128 port 6320 daemonize yes pidfile "/var/run/redis_6320.pid" logfile "/var/run/redis_6320.log" requirepass "pwd@123" 192.168.142.130 /usr/local/src/redis-5.0.3/redis_6310.conf bind 192.168.142.130 port 6310 daemonize yes pidfile "/var/run/redis_6310.pid" logfile "/var/run/redis_6310.log" masterauth "pwd@123" requirepass "pwd@123" replicaof 192.168.142.128 6320 192.168.142.130 /usr/local/src/redis-5.0.3/redis_6311.conf bind 192.168.142.130 port 6311 daemonize yes pidfile "/var/run/redis_6311.pid" logfile "/var/run/redis_6311.log" requirepass "pwd@123" masterauth "pwd@123" replicaof 192.168.142.128 6320
3、redis密码管理( 插播 补充下 redis密码管理 )
1)、如何初始化redis的密码？
总共2个步骤： a.在配置文件中有个参数： requirepass 这个就是配置redis访问密码的参数。 比如 requirepass test123 b.配置文件中参数生效需要重启重启redis 。
2)、不重启redis如何配置密码?
a. 在配置文件中配置requirepass的密码（当redis重启时密码依然有效）。 [root@localhost redis-5.0.3]# pwd /usr/local/src/redis-5.0.3 [root@localhost redis-5.0.3]# vim redis_6320.conf requirepass "pwd@123" b. 进入redis重定义参数 查看当前的密码： [root@localhost src]# redis-cli -h 192.168.142.128 -p 6320 192.168.142.128:6320> config get requirepass 1) "requirepass" 2) "" 192.168.142.128:6320> 显示密码是空的,然后设置密码： 192.168.142.128:6320> config set requirepass pwd@123 OK 再次查询密码： 192.168.142.128:6320> config get requirepass (error) NOAUTH Authentication required. 此时报错了！现在只需要密码认证就可以了。 192.168.142.128:6320> auth pwd@123 OK 再次查询密码： 192.168.142.128:6320> config get requirepass 1) "requirepass" 2) "pwd@123" 密码已经得到修改。 当到了可以重启redis的时候 由于配置参数已经修改 所以密码会自动生效。 要是配置参数没添加密码 那么redis重启 密码将相当于没有设置。
3)、如何登录有密码的redis？
a.在登录的时候 密码就输入 [root@localhost src]# redis-cli -h 192.168.142.128 -p 6320 -a pwd@123 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 192.168.142.128:6320> 192.168.142.128:6320> config get requirepass 1) "requirepass" 2) "pwd@123" 192.168.142.128:6320> b.先登录再验证： [root@localhost src]# redis-cli -h 192.168.142.128 -p 6320 192.168.142.128:6320> 192.168.142.128:6320> config get requirepass (error) NOAUTH Authentication required. 192.168.142.128:6320> auth pwd@123 OK 192.168.142.128:6320> get config "1" 192.168.142.128:6320> config get requirepass 1) "requirepass" 2) "pwd@123"
4)、master 有密码,slave 如何配置?
当master 有密码的时候 配置slave 的时候 相应的密码参数也得相应的配置好。不然slave 是无法进行正常复制的。 相应的参数是： #masterauth 比如: masterauth mstpassword
4、配置主从节点（通过info replication查看主从关系）,手动切换Master，启用哨兵自动切换主从
1).分别启动1主2从 redis
###192.168.142.128(主： 6320) [root@localhost src]# pwd /usr/local/src/redis-5.0.3/src [root@localhost src]# ./redis-server ../redis_6320.conf [root@localhost ~]# ps -ef |grep redis root 52761 1 0 00:02 ? 00:00:00 ./redis-server 192.168.142.128:6320 root 52833 52769 0 00:02 pts/1 00:00:00 grep --color=auto redis [root@localhost src]# redis-cli -h 192.168.142.128 -p 6320 -a pwd@123 ###192.168.142.130(从： 6310) [root@localhost src]# pwd /usr/local/src/redis-5.0.3/src [root@localhost src]# ./redis-server ../redis_6310.conf [root@localhost src]# redis-cli -h 192.168.142.130 -p 6310 -a pwd@123 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 192.168.142.130:6310> ###192.168.142.130(从： 6311) [root@localhost ~]# cd /usr/local/src/redis-5.0.3/src [root@localhost src]# ./redis-server ../redis_6311.conf [root@localhost src]# redis-cli -h 192.168.142.130 -p 6311 -a pwd@123 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 192.168.142.130:6311> ###192.168.142.130 从查看redis信息 [root@localhost ~]# ps -ef |grep redis root 54199 1 0 00:50 ? 00:00:00 ./redis-server 192.168.142.130:6310 root 54277 8062 0 00:51 pts/0 00:00:00 redis-cli -h 192.168.142.130 -p 6310 -a pwd@123 root 54407 1 0 00:52 ? 00:00:00 ./redis-server 192.168.142.130:6311 root 54464 54349 0 00:53 pts/2 00:00:00 redis-cli -h 192.168.142.130 -p 6311 -a pwd@123 root 54485 54205 0 00:53 pts/1 00:00:00 grep --color=auto redis
2).查看主从关系 （info replication）
5、Master节点设置key后异步同步到Slaver节点；Slaver节点只能读取数据，不能修改
1)、查看 192.168.142.128 (主) 的执行日志文件 /var/run/redis_6320.log，可以看到，Master 设置的key 已经异步同步到了
192.168.142.130(从： 6310)、192.168.142.130(从： 6311)
192.168.142.130:6310> get config "1" 192.168.142.130:6311> get config "1"
2)、跟新 slaver 节点key的值
6、主节点挂掉后，手动将S1子节点升级为Master（命令：slaveof no one 手动将Slaver节点升级为Master节点）
操作步骤如下： a)Master节点：Shutdown关闭节点 b)Slaver1节点：slaveof no one将其升级为Master节点 c)Slaver2节点：使用slaveof 192.168.142.130 6310 重连Slaver1 将其视为Master节点 d)原来的Master节点：重新启动后，可以使用slaveof 192.168.142.130 6310 连接Slaver2将其视为Master节点，自己成为Slaver节点 ./redis-server ../redis_6320.conf --slaveof 192.168.142.130 6310 注意：redis(从) 默认是不能写的。
7、使用哨兵模式，自动监视Master节点，当前挂掉后，自动将Slaver节点变为Master节点
a) 192.168.142.130(从： 6310) 拷贝一份新的 sentinel.conf [root@localhost redis-5.0.3]# cp sentinel.conf sentinel_6310.conf b) sentinel_6310.conf配置文件，修改sentinel monitor mymaster 192.168.142.130 6310 1，其它使用默认即可 host6379 主机名称，随便起 主机IP 端口 1表示选举，某个slaver得到超过1票则成成为Master节点 注意：如果配置密码访问，需添加 sentinel auth-pass mymaster pwd@123 c) 启动sentinel： ./redis-sentinel ../sentinel_6310.conf
8、手动shutdown Master节点后，等待一段时间（大概一分钟），sentinel会重新选举Master节点。
下面将6320选举为Master节点，6311自动重连6320的Master节点 6310 原来的Master节点重启后变成Slaver节点 [root@localhost src]# ./redis-sentinel ../sentinel_6310.conf ##启动哨兵 [root@localhost ~]# ps -ef | grep redis root 9159 8003 0 11:54 pts/1 00:00:00 tail -f /var/run/redis_6310.log root 9161 1 0 11:55 ? 00:00:00 ./redis-server 192.168.142.130:6310 root 9173 7927 0 11:55 pts/0 00:00:00 ./redis-cli -h 192.168.142.130 -p 6310 -a pwd@123 root 9175 8236 0 11:55 pts/3 00:00:00 tail -f /var/run/redis_6311.log root 9177 1 0 11:56 ? 00:00:00 ./redis-server 192.168.142.130:6311 root 9182 8106 0 11:56 pts/2 00:00:00 ./redis-cli -h 192.168.142.130 -p 6311 -a pwd@123 root 9219 8281 0 11:59 pts/4 00:00:00 ./redis-sentinel *:26379 [sentinel] root 9246 8619 0 12:00 pts/5 00:00:00 grep --color=auto redis [root@localhost ~]# kill -9 9161 ##手动停止Master 192.168.142.130(6310) ###显示启动哨兵后的详细信息 [root@localhost src]# ./redis-sentinel ../sentinel_6310.conf 9219:X 07 Apr 2019 11:59:40.751 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 9219:X 07 Apr 2019 11:59:40.751 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=9219, just started 9219:X 07 Apr 2019 11:59:40.751 # Configuration loaded 9219:X 07 Apr 2019 11:59:40.752 * Increased maximum number of open files to 10032 (it was originally set to 1024). _._ _.-``__ ''-._ _.-`` `. `_. ''-._ Redis 5.0.3 (00000000/0) 64 bit .-`` .-```. ```\/ _.,_ ''-._ ( ' , .-` | `, ) Running in sentinel mode |`-._`-...-` __...-.``-._|'` _.-'| Port: 26379 | `-._ `._ / _.-' | PID: 9219 `-._ `-._ `-./ _.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | http://redis.io `-._ `-._`-.__.-'_.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | `-._ `-._`-.__.-'_.-' _.-' `-._ `-.__.-' _.-' `-._ _.-' `-.__.-' 9219:X 07 Apr 2019 11:59:40.754 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 9219:X 07 Apr 2019 11:59:40.754 # Sentinel ID is 3d9c2745cc267a7d6cc9659318261378442eb562 9219:X 07 Apr 2019 11:59:40.755 # +monitor master mymaster 192.168.142.130 6311 quorum 1 9219:X 07 Apr 2019 12:00:30.813 # +sdown master mymaster 192.168.142.130 6311 #说明master服务已经宕机 9219:X 07 Apr 2019 12:00:30.813 # +odown master mymaster 192.168.142.130 6311 #quorum 1/1 9219:X 07 Apr 2019 12:00:30.813 # +new-epoch 3 9219:X 07 Apr 2019 12:00:30.813 # +try-failover master mymaster 192.168.142.130 6311 #开始恢复故障 9219:X 07 Apr 2019 12:00:30.924 # +vote-for-leader 3d9c2745cc267a7d6cc9659318261378442eb562 3 #投票选举哨兵leader，现在就一个哨兵所以leader就自己 9219:X 07 Apr 2019 12:00:30.924 # +elected-leader master mymaster 192.168.142.130 6311 #选中leader 9219:X 07 Apr 2019 12:00:30.924 # +failover-state-select-slave master mymaster 192.168.142.130 6311 #选中其中的一个slave当做master 9219:X 07 Apr 2019 12:00:30.977 # +selected-slave slave 192.168.142.128:6320 192.168.142.128 6320 @ mymaster 192.168.142.130 6311 #选中6320 9219:X 07 Apr 2019 12:00:30.977 * +failover-state-send-slaveof-noone slave 192.168.142.128:6320 192.168.142.128 6320 @ mymaster 192.168.142.130 6311 #发送slaveof no one命令 9219:X 07 Apr 2019 12:00:31.068 * +failover-state-wait-promotion slave 192.168.142.128:6320 192.168.142.128 6320 @ mymaster 192.168.142.130 6311 #等待升级master 9219:X 07 Apr 2019 12:00:31.984 # +promoted-slave slave 192.168.142.128:6320 192.168.142.128 6320 @ mymaster 192.168.142.130 6311 #升级6320为master 9219:X 07 Apr 2019 12:00:31.984 # +failover-state-reconf-slaves master mymaster 192.168.142.130 6311 9219:X 07 Apr 2019 12:00:32.004 * +slave-reconf-sent slave 192.168.142.130:6310 192.168.142.130 6310 @ mymaster 192.168.142.130 6311 9219:X 07 Apr 2019 12:00:32.959 * +slave-reconf-inprog slave 192.168.142.130:6310 192.168.142.130 6310 @ mymaster 192.168.142.130 6311 9219:X 07 Apr 2019 12:00:32.959 * +slave-reconf-done slave 192.168.142.130:6310 192.168.142.130 6310 @ mymaster 192.168.142.130 6311 9219:X 07 Apr 2019 12:00:33.041 # +failover-end master mymaster 192.168.142.130 6311 #故障恢复完成 9219:X 07 Apr 2019 12:00:33.041 # +switch-master mymaster 192.168.142.130 6311 192.168.142.128 6320 #主数据库从6310转变为6320 (端口) 9219:X 07 Apr 2019 12:00:33.042 * +slave slave 192.168.142.130:6310 192.168.142.130 6310 @ mymaster 192.168.142.128 6320 #添加6310为6320的从库 9219:X 07 Apr 2019 12:00:33.042 * +slave slave 192.168.142.130:6311 192.168.142.130 6311 @ mymaster 192.168.142.128 6320 #添加6311为6320的从库 9219:X 07 Apr 2019 12:01:16.481 # +sdown slave 192.168.142.130:6310 192.168.142.130 6310 @ mymaster 192.168.142.128 6320 #发现6310已经宕机，等待6310的恢复 9219:X 07 Apr 2019 12:03:34.099 * +fix-slave-config slave 192.168.142.130:6311 192.168.142.130 6311 @ mymaster 192.168.142.128 6320 ###查看 6320的状态 192.168.142.128:6320> info replication # Replication role:master connected_slaves:0 #当前尚未连接任一从库 master_replid:6cf7f795ecae13d380900f62192bfc32e6d81329 master_replid2:bcbb40938954f716ffd23b9b563c78955d90f6a2 master_repl_offset:9423 second_repl_offset:3840 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:141 repl_backlog_histlen:9283 192.168.142.128:6320> info replication # Replication role:master connected_slaves:1 #当前已经连上一个从库 6311 slave0:ip=192.168.142.130,port=6311,state=online,offset=26715,lag=1 master_replid:6cf7f795ecae13d380900f62192bfc32e6d81329 master_replid2:bcbb40938954f716ffd23b9b563c78955d90f6a2 master_repl_offset:26715 second_repl_offset:3840 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:141 repl_backlog_histlen:26575 ##可以看出，目前，6320为master，拥有一个slave为6311. ##接下来，我们恢复6310查看状态： [root@localhost src]# ./redis-server ../redis_6310.conf --slaveof 192.168.142.128 6320 [root@localhost src]# ./redis-cli -h 192.168.142.130 -p 6310 -a pwd@123 9219:X 07 Apr 2019 12:07:54.652 * +reboot slave 192.168.142.130:6310 192.168.142.130 6310 @ mymaster 192.168.142.128 6320 9219:X 07 Apr 2019 12:07:54.719 # -sdown slave 192.168.142.130:6310 192.168.142.130 6310 @ mymaster 192.168.142.128 6320 #6310已经恢复服务 ##再次查看6320状态、并测试是否已经完全启用新的Master 192.168.142.128:6320> info replication # Replication role:master connected_slaves:2 #当前已经连上两个从库 6311、6310 slave0:ip=192.168.142.130,port=6311,state=online,offset=36481,lag=0 slave1:ip=192.168.142.130,port=6310,state=online,offset=36481,lag=0 master_replid:6cf7f795ecae13d380900f62192bfc32e6d81329 master_replid2:bcbb40938954f716ffd23b9b563c78955d90f6a2 master_repl_offset:36481 second_repl_offset:3840 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:141 repl_backlog_histlen:36341 192.168.142.128:6320> 192.168.142.128:6320> get redis "key4" 192.168.142.128:6320> set redis key5 OK 192.168.142.128:6320> get redis "key5" 192.168.142.128:6320> 192.168.142.130:6310> get redis "key5" 192.168.142.130:6310> 192.168.142.130:6311> get redis "key5" 192.168.142.130:6311>
5、配置多个哨兵(可在主从上同时部署哨兵)
vim sentinel.conf 输入内容： sentinel monitor mymaster 1 192.168.142.128 6320 1 sentinel monitor mymaster 2 192.168.142.130 6311 1
6、基本原理
关于哨兵的原理，关键是了解以下几个概念。
（1）定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：通过向主从节点发送info命令获取最新的主从结构；通过发布订阅功能获取其他哨兵节点的信息；通过向其他节点发送ping命令进行心跳检测，判断是否下线。
（2）主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。
（3）客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。
需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。
（4）选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。
监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。
（5）故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：
在从节点中选择新的主节点：选择的原则是，首先过滤掉不健康的从节点；然后选择优先级最高的从节点(由slave-priority指定)；如果优先级无法区分，则选择复制偏移量最大的从节点；如果仍无法区分，则选择runid最小的从节点。
更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
将已经下线的主节点(即6379)设置为新的主节点的从节点，当6379重新上线后，它会成为新的主节点的从节点。
哨兵系统的搭建过程，有几点需要注意：
（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。 （2）哨兵节点本质上是redis节点。 （3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。 （4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。 （5）本章的例子中，一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条sentinel monitor即可实现。
总结：
1.可以通过slaveof no one命令将Slaver升级为Master（当Master挂掉时，手动将某个Slaver变为Master） 2.可以通过sentinel哨兵模式监控Master，当Master挂掉时自动选举Slaver变为Master，其它Slaver自动重连新的Master 3.在故障转移阶段，哨兵和主从节点的配置文件都会被改写。 对于主从节点，主要是slaveof配置的变化：新的主节点没有了slaveof配置，其从节点则slaveof新的主节点。 对于哨兵节点，除了主从节点信息的变化，纪元(epoch)也会变化，下图中可以看到纪元相关的参数都+1了。
常用命令：
1、哨兵节点的启动有两种方式，二者作用是完全相同的： redis-sentinel sentinel-26379.conf redis-server sentinel-26379.conf --sentinel 2、通过redis-cli连接哨兵节点进行验证： 192.168.142.128:6320> info Sentinel 其中，dir只是显式声明了数据和日志所在的目录（在哨兵语境下只有日志）；known-slave和known-sentinel显示哨兵已经发现了从节点和其他哨兵；带有epoch的参数与配置纪元有关（配置纪元是一个从0开始的计数器，每进行一次领导者哨兵选举，都会+1；领导者哨兵选举是故障转移阶段的一个操作，在后文原理部分会介绍）。 3. 哨兵节点支持的命令 哨兵节点作为运行在特殊模式下的redis节点，其支持的命令与普通的redis节点不同。在运维中，我们可以通过这些命令查询或修改 哨兵系统；不过更重要的是，哨兵系统要实现故障发现、故障转移等各种功能，离不开哨兵节点之间的通信，而通信的很大一部分是通过 哨兵节点支持的命令来实现的。下面介绍哨兵节点支持的主要命令。 1）基础查询：通过这些命令，可以查询哨兵系统的拓扑结构、节点信息、配置信息等。 info sentinel：获取监控的所有主节点的基本信息 sentinel masters：获取监控的所有主节点的详细信息 sentinel master mymaster：获取监控的主节点mymaster的详细信息 sentinel slaves mymaster：获取监控的主节点mymaster的从节点的详细信息 sentinel sentinels mymaster：获取监控的主节点mymaster的哨兵节点的详细信息 sentinel get-master-addr-by-name mymaster：获取监控的主节点mymaster的地址信息 sentinel is-master-down-by-addr：哨兵节点之间可以通过该命令询问主节点是否下线，从而对是否客观下线做出判断 （2）增加/移除对主节点的监控 sentinel monitor mymaster2 192.168.92.128 16379 2：与部署哨兵节点时配置文件中的sentinel monitor功能完全一样 sentinel remove mymaster2：取消当前哨兵节点对主节点mymaster2的监控 3）强制故障转移 sentinel failover mymaster：该命令可以强制对mymaster执行故障转移，即便当前的主节点运行完好； 例如，如果当前主节点所在机器即将报废，便可以提前通过failover命令进行故障转移。
本文为崔凯原创文章,转载无需和我联系,但请注明来自冷暖自知一抹茶ckhttp://www.cksite.cn
- 上一篇： 深入学习Redis
- 下一篇： MySQL优化之explain
- 最新评论
- 总共0条评论
