Sentinel模式04
Sentinel模式
Sentinel模式介绍
主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此sentinel应运而生。
sentinel中文含义为哨兵，顾名思义，它的作用就是监控redis集群的运行状况
功能
1.监控（Monitoring）：
Sentinel会'不断地检查'你的主服务器和从服务器是否运作正常。(每秒一次ping)
2.提醒（Notification）：
当被监控的某个Redis服务器出现问题时，Sentinel可以'通过API'向管理员或者其他应用程序发送'通知'。
3.自动故障迁移（Automatic failover）：
#sentinel发现主服务器是根据配置文件发现的
一次故障转移操作由以下步骤组成：
1.发现主服务器已经进入'客观下线状态'。
2.基于Raft leader election协议，进行'投票选举'
3.如果当选失败，那么在设定的故障迁移超时时间的两倍之后，'重新尝试当选'。如果当选成功，那么执行以下步骤。
1）选出一个从服务器，并将它升级为主服务器。(#多种选择方法)
2）向被选中的从服务器发送 'SLAVEOF NO ONE '命令，让它转变为主服务器。
3）通过'发布与订阅功能'，将更新后的配置传播给所有其他Sentinel，其他Sentinel对它们自己的配置进行更新。
4）向已下线主服务器的从服务器发送'SLAVEOF命令'，让它们去复制新的主服务器。
5）当所有从服务器都已经开始复制新的主服务器时
6）集群也会向客户端'返回新主服务器的地址'，使得集群可以使用新主服务器代替失效服务器。
#sentinel选择主库的规则
1.在失效主服务器属下的从服务器当中，那些被标记为主观下线、已断线、或者最后一次回复PING命令的时间大于五秒钟的从服务器都会被淘汰。
2.在失效主服务器属下的从服务器当中，那些与失效主服务器连接断开的时长超过down-after选项指定的时长十倍的从服务器都会被淘汰。
3.在经历了以上两轮淘汰之后剩下来的从服务器中，我们选出'复制偏移量'（数据量）（replication offset）最大的那个从服务器作为新的主服务器；如果复制偏移量不可用，或者从服务器的复制偏移量相同，那么带有'最小运行ID'的那个从服务器成为新的主服务器。（#或最大优先级）
#简单来说，我们可以将Sentinel配置看作是一个带有版本号的状态。一个状态会以最后写入者胜出（last-write-wins）的方式（也即是，最新的配置总是胜出）传播至所有其他Sentinel。
#sentinel仅仅解决了集群的单点问题
特点
* sentinel模式是建立在'主从模式的基础上'，如果只有一个Redis节点，sentinel就没有任何意义
* 当master挂了以后，sentinel会在slave中选择一个做为master，并'修改它们的配置文件'，其他slave的配置文件也会被修改，比如'slaveof属性'会指向新的master
* 当master重新启动后，它将不再是master而是'做为slave'接收新的master的同步数据(#以从库身份加入)
* sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个'sentinel集群'
* 多sentinel配置的时候，'sentinel之间'也会自动监控
* 当主从模式配置'密码'时，sentinel也会同步将配置信息修改到配置文件中，不需要担心
* 一个sentinel或sentinel集群可以管理'多个主从Redis'，多个sentinel也可以监控'同一个redis'
* sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了
#sentinel的作用，必须在redis主从已经做好的前提下
工作机制
* 每个sentinel以'每10秒钟一次'的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令
* 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被这个sentinel'标记为主观下线'。
* 如果一个master被标记为主观下线，则正在监视这个master的'所有sentinel'要以每秒一次的频率确认master的确进入了主观下线状态
* 当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则'master会被标记为客观下线 '
* 在一般情况下， 每个sentinel会以每' 10 秒一次'的频率向它已知的所有master，slave发送 INFO 命令
* 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为' 1 秒一次 '
* 若没有'足够数量'的sentinel同意master已经下线，master的客观下线状态就会被移除；
若master重新向sentinel的 PING 命令返回'有效回复'，master的主观下线状态就会被移除
当使用sentinel模式的时候，客户端就不要'直接连接'Redis，'而是连接'sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。
Redis的Sentinel中关于'下线'（down）有两个不同的概念：
1）主观下线（Subjectively Down， 简称 SDOWN）指的是'单个 Sentinel' 实例对服务器做出的下线判断。
2）客观下线（Objectively Down，简称 ODOWN）指的是'多个Sentinel实例'在对同一个服务器做出SDOWN判断，并且通过SENTINEL' is-master-down-by-addr'命令互相交流之后，得出的服务器下线判断。（一个 Sentinel可以通过向另一个Sentinel发送SENTINEL is-master-down-by-addr命令来询问对方是否认为给定的服务器已下线。）
#sentinel通过ping命令判断是否存活，通过订阅发送消息，
#通过订阅相同的slave，sentinel之间可以交流投票数
#leader sentinel终止故障转移
Sentinel模式搭建
| 角色 | ip | 端口 |
|---|---|---|
| master Sentinel | 172.16.1.52 | 6302 26379 |
| slave | 172.16.1.53 | 6303 |
| slave | 172.16.1.54 | 6304 |
0.检查主从状态，根据主从状态编辑配置文件
1.安装或选择一台Redis用来配置sentinel实例
2.编辑sentinel配置文件(#编辑的时候注释要去掉)
mkdir /service/redis/26379/
[root@db02 ~]# vim /service/redis/26379/sentinel.conf
#sentinel的端口
port 26379
daemonize yes
pidfile /service/redis/26379/sentinel.pid
logfile /service/redis/26379/sentinel.log
dir /service/redis/26379
bind 172.16.1.52 127.0.0.1
#主库的ip 端口和sentinel的半数以上
sentinel monitor mymaster 172.16.1.52 6379 1
#主库的密码
sentinel auth-pass mymaster 123
#sentinel的ping的返回时间x,超过该时间则认为该实例下线
sentinel down-after-milliseconds mymaster 5000
#sentinel ping该下线主库的从库，从xx秒内返回pong的这些从库中选一个主库
sentinel failover-timeout mymaster 180000
#同时同步主库的从库的数量
sentinel parallel-syncs mymaster 1
3.启动sentinel
[root@db02 ~]# redis-sentinel /service/redis/26379/sentinel.conf
4.关闭主库Redis
[root@db02 ~]# redis-cli -a 123 -p 6302 shutdown
5.登录从库，查看主库是谁
[root@db03 ~]# redis-cli -a 123 -p 6303
127.0.0.1:6303> info replication
6.修复坏掉的主库，启动
[root@db02 ~]# redis-server /service/redis/6302/redis.conf
7.登录该实例，查看主从
[root@db02 ~]# redis-cli -a 123 -p 6302
127.0.0.1:6302> info replication
#6379 1
端口后面的这个数值取决于sentinel的数量，与投票有关（半数以上）
#主库根据slave序号优先选择谁为主库
slave0:ip=172.16.1.53,port=6303,state=online,offset=23539,lag=1
slave1:ip=172.16.1.52,port=6302,state=online,offset=23539,lag=0
#根据偏移量和优先级判断谁为主库
127.0.0.1:6302> info replication
slave_repl_offset:41850 （偏移量=数据量）
slave_priority:100 （优先级越高，下次主库就是谁）
sentinel日志
[root@db02 ~]# tailf /service/redis/26379/sentinel.log
129161:X 06 Aug 13:45:55.330 # +monitor master mymaster 172.16.1.52 6379 quorum 1
129161:X 06 Aug 13:46:00.368 # +sdown master mymaster 172.16.1.52 6379
129161:X 06 Aug 13:46:00.368 # +odown master mymaster 172.16.1.52 6379 #quorum 1/1
129161:X 06 Aug 13:46:00.368 # +new-epoch 3
129161:X 06 Aug 13:46:00.368 # +try-failover master mymaster 172.16.1.52 6379
129161:X 06 Aug 13:46:00.369 # +vote-for-leader fda1d8e2784d51f26e24ae1d42a4a66c7eda0ece 3
129161:X 06 Aug 13:46:00.369 # +elected-leader master mymaster 172.16.1.52 6379
129161:X 06 Aug 13:46:00.369 # +failover-state-select-slave master mymaster 172.16.1.52 6379
129161:X 06 Aug 13:46:00.424 # -failover-abort-no-good-slave master mymaster 172.16.1.52 6379
129161:X 06 Aug 13:46:00.525 # Next failover delay: I will not start a failover before Thu Aug 6 13:52:00 2020
· +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 模式。
sentinel管理命令（不常用）
#连接sentinel管理端口
[root@db01 ~]# redis-cli -a 123 -p 26379
#检测状态，返回PONG(说明sentinel监控下，主库状态正常)
127.0.0.1:26379> ping
PONG
#列出所有被监视的主服务器
127.0.0.1:26380> SENTINEL masters
#列出所有被监视的从服务器
127.0.0.1:26380> SENTINEL slaves mymaster
#返回给定名字的主服务器的IP地址和端口号
127.0.0.1:26380> SENTINEL get-master-addr-by-name mymaster
1) "172.16.1.51"
2) "6379
#重置所有名字和给定模式
127.0.0.1:26380> SENTINEL reset mymaster
#当主服务器失效时，在不询问其他Sentinel意见的情况下，强制开始一次自动故障迁移。
127.0.0.1:26380> SENTINEL failover mymaster
设置权重，指定主库的优先级
#查看db02的权重
172.16.1.52:6379> CONFIG GET slave-priority
1) "slave-priority"
2) "100"
#修改db02的权重值为0
172.16.1.52:6379> CONFIG set slave-priority 0
OK
172.16.1.52:6379> CONFIG GET slave-priority
1) "slave-priority"
2) "0"
#权重值越低越不会优先切换为主库
#强制开始一次自动故障迁移
127.0.0.1:26380> SENTINEL failover mymaster
#再次查看，主库为db03
172.16.1.53:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.16.1.52,port=6379,state=online,offset=71377,lag=0
slave1:ip=172.16.1.51,port=6379,state=online,offset=71377,lag=0
master_repl_offset:71514
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:70496
repl_backlog_histlen:1019
