Redis数据库--哨兵管理
一、Redis哨兵介绍及功能：
1.哨兵简介
Redis 的主从模式下，主节点一旦发生故障不能提供服务，需要人工干预，将从节点晋升为主节点， 同时还需要修改客户端配置。对于很多应用场景这种方式无法接受。 Sentinel（哨兵）架构解决了 redis 主从人工干预的问题。 Redis Sentinel 是 redis 的高可用实现方案，实际生产环境中，对提高整个系统可用性非常有帮助的。哨兵的本质也是单独的一个Redis节点，但Sentinel是一个特殊的节点，不负责处理任何数据，只负责监控转移，并且哨兵之间的信息是互通共享的，每个成员之间信息都是当前master节点的最新状态
2.哨兵主要功能
Redis Sentinel 是一个分布式系统， Redis Sentinel 为 Redis 提供高可用性。可以在没有人为干预的情 况下阻止某种类型的故障。 Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）该系统执行以下三个任务： 1.监控（Monitoring）： Sentinel 会不断地定期检查你的主服务器和从服务器是否运作正常。 2.提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。 3.自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从 服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效 的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
哨兵基础构架
说明：Redis数据库通过哨兵实现靠可用的依据依然来源于数据库的主从复制，因此，在Redis数据库搭建哨兵管理时同时也要配置主从复制的相关操作
3.哨兵工作流程
由于Redis哨兵的特性，信息互通共享，且信息为当前主节点的最新状态，根据上图所示，当当前Master节点发生故障，相同服务器上的哨兵节点（Sentinel02节点）也将无法正常工作，此时整个哨兵管理系统就会通过信息互通共享感知到Master节点故障的信息，之后哨兵节点就会进行选举操作，选举出Slave01和Slave02其中一台充当主节点暂时使用，等Master节点修复恢复后，可再次手动使其升级回到主节点，继续使用上图的架构。
注意：在整个流程中，我们不难发现在实际的生产环境中，为了实现大量数据能够缓存到Redis数据库中，就必须要指定主节点的IP，而当主节点故障时，后台代码就不能有效识别到主节点代码，还需手动完成IP地址转化，这样哨兵就失去了本身的意义，因此，需要在哨兵节点上插入一条列表，使所有redis服务器的IP地址，均在列表，代码优先读取列表IP地址，通过哨兵信息互通共享，找到master节点，实现IP自动获取，但缺陷就在于读取IP需要俩次过程，浪费部分服务器性能，同时，由于哨兵依然基于主从复制，从节点的只读特性导致，写入数据的真实大小依然只限于主节点的内存大小。
代码正常获取IP地址
主节点故障代码获取
二、哨兵节点安装部署
1.安装3个Redis节点
Redis数据库安装部署详情参考：https://www.jianshu.com/p/204dcfc4d0ab
注意：搭建Redis单节点时，请将配置文件中的密码认证功能关闭
cat /opt/redis_6379/conf/redis_6379.conf |grep "requirepass"
#requirepass "123456"
2.安装部署3个哨兵节点
第一步：创建数据存储目录
mkdir -p /data/redis_26379
mkdir -p /opt/redis_26379/{conf,pid,logs}
第二步：配置哨兵节点的配置文件
db01的配置：
vim /opt/redis_26379/conf/redis_26379.conf
bind 10.0.0.51
port 26379
daemonize yes
logfile /opt/redis_26379/logs/redis_26379.log
dir /data/redis_26379
###哨兵监控主节点信息，主节点名称为mymaster（任意起名），主节点IP地址、端口号、判断主节点失败，两个 sentinel 节点同意
sentinel monitor mymaster 10.0.0.51 6379 2
###哨兵节点连接主节点时间限制（默认毫秒）；选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
sentinel down-after-milliseconds mymaster 3000
###向新的主节点发起复制操作的从节点个数，1 ：轮询发起复制
sentinel parallel-syncs mymaster 1
###故障转移超时时间（默认毫秒），即发现主节故障后转移超过18000毫秒，则默认转移失败
sentinel failover-timeout mymaster 18000
db02的配置：
vim /opt/redis_26379/conf/redis_26379.conf
bind 10.0.0.52
port 26379
daemonize yes
logfile /opt/redis_26379/logs/redis_26379.log
dir /data/redis_26379
###哨兵监控主节点信息，主节点名称为mymaster（任意起名），主节点IP地址、端口号、判断主节点失败，两个 sentinel 节点同意
sentinel monitor mymaster 10.0.0.51 6379 2
###哨兵节点连接主节点时间限制（默认毫秒）；选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
sentinel down-after-milliseconds mymaster 3000
###向新的主节点发起复制操作的从节点个数，1 ：轮询发起复制
sentinel parallel-syncs mymaster 1
###故障转移超时时间（默认毫秒），即发现主节故障后转移超过18000毫秒，则默认转移失败
sentinel failover-timeout mymaster 18000
db03的配置：
vim /opt/redis_26379/conf/redis_26379.conf
bind 10.0.0.53
port 26379
daemonize yes
logfile /opt/redis_26379/logs/redis_26379.log
dir /data/redis_26379
###哨兵监控主节点信息，主节点名称为mymaster（任意起名），主节点IP地址、端口号、判断主节点失败，两个 sentinel 节点同意
sentinel monitor mymaster 10.0.0.51 6379 2
###哨兵节点连接主节点时间限制（默认毫秒）；选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
sentinel down-after-milliseconds mymaster 3000
###向新的主节点发起复制操作的从节点个数，1 ：轮询发起复制
sentinel parallel-syncs mymaster 1
###故障转移超时时间（默认毫秒），即发现主节故障后转移超过18000毫秒，则默认转移失败
sentinel failover-timeout mymaster 18000
第三步：配置主从复制
redis-cli -h 10.0.0.52 slaveof 10.0.0.51 6379
redis-cli -h 10.0.0.53 slaveof 10.0.0.51 6379
说明：此方式为远程命令行方式开启从库主从复制，且为临时开启，建议修改配置文件永久开启
第四步：启动所有单节点Redis数据库
redis-server /opt/redis_6379/conf/redis_6379.conf
第五步：启动哨兵
redis-sentinel /opt/redis_26379/conf/redis_26379.conf
注意：当基于主从复制的哨兵管理系统正常启动完毕后，在其配置文件中，会出现以下内容，如图所示：
此时就证明，在整个哨兵中所有的信息使互通共享的，而实现信息共享的方式就是通过生产配置文件来实现的，所以不要改动该文件中的任意字符，保证哨兵管理安全持久。当所有节点启动后,配置文件的内容发生了变化,体现在三个方面: 1)Sentinel 节点自动发现了从节点,其余 Sentinel 节点 2)去掉了默认配置,例如 parallel-syncs failover-timeout 参数 3)添加了配置纪元相关参数
第六步：哨兵节点登录
redis-cli -h 10.0.0.51 -p 26379
redis-cli -h 10.0.0.52 -p 26379
redis-cli -h 10.0.0.53 -p 26379
说明：在登陆到哨兵节点后，由于哨兵是一个特殊的Redis节点，不处理任何数据，因此哨兵节点的有单独的命令，进行对哨兵节点的操作，总结如下
Info Sentinel #显示当前哨兵节点全部的状态信息，包括名称，节点个数等
Sentinel masters #显示所有哨兵管理系统中的所有主节点信息和状态
Sentinel master <master name> #显示指定主节点的信息和状态
Sentinel slaves <master name> #显示指定主节点下的所有从库以及它们的状态
Sentinel sentinels <master name> #显示指定哨兵节点的信息和状态
Sentinel get-master-addr-by-name <master name> #返回指定主节点的ip和端口，如果正在进行failover或者failover已经完成，将会显示被提升为主节点的slave的ip和端口。
Sentinel failover <master name> #强制sentinel执行failover，并且不需要得到其他sentinel的同意。但是failover后会将最新的配置发送给其他sentinel。
Sentinel flushconfig #将配置强制刷新到本地文件
SENTINEL reset <pattern> #重置名字匹配该正则表达式的所有的master的状态信息，清楚其之前的状态信息，以及slaves信息。
三、故障模拟检验
1..验证各哨兵节点主节点信息
redis-cli -h 10.0.0.51 -p 26379 Sentinel get-master-addr-by-name mymaster
1) "10.0.0.51"
2) "6379"
redis-cli -h 10.0.0.52 -p 26379 Sentinel get-master-addr-by-name mymaster
1) "10.0.0.51"
2) "6379"
redis-cli -h 10.0.0.53 -p 26379 Sentinel get-master-addr-by-name mymaster
1) "10.0.0.51"
2) "6379"
2.模拟故障转移
- 关闭主节点服务上的所有redis进程
pkill redis
- 观察其他2个节点会不会发生选举
tail -f /opt/redis_26379/logs/redis_26379.log
从节点故障转移过程
- 查看配置文件里会不会自动更新
从节点配置文件变更
- 查看新的主节点能不能写入
redis-cli -h 10.0.0.52 -p 6379 set km vm
OK
- 查看从节点能否正常同步
redis-cli -h 10.0.0.53 -p 6379 get km
"vm"
3.模拟故障修复上线
- 启动单节点及哨兵节点
redis-server /opt/redis_6379/conf/redis_6379.conf
redis-sentinel /opt/redis_26379/conf/redis_26379.conf
- 查看原主节点配置文件变化
cat /opt/redis_26379/conf/redis_26379.conf
bind 10.0.0.51 127.0.0.1
port 26379
daemonize yes
logfile "/opt/redis_26379/logs/redis_26379.log"
dir "/data/redis_26379"
sentinel myid 79052b5f901edb979578856de3412ab2272a416c
sentinel monitor mymaster 10.0.0.52 6379 2
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 18000
# Generated by CONFIG REWRITE
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
sentinel known-slave mymaster 10.0.0.51 6379
sentinel known-slave mymaster 10.0.0.53 6379
sentinel known-sentinel mymaster 10.0.0.53 26379 19e37e11882dcdc47ca8aa73a8207f4387e12254
sentinel known-sentinel mymaster 10.0.0.52 26379 da32db2c17d0718e208fd6db227ffb61d5f5dd74
sentinel current-epoch 0
区别：主节点发生变更为10.0.0.52，哨兵节点通知复制节点分别为sentinel known-slave mymaster 10.0.0.51 6379、sentinel known-slave mymaster 10.0.0.53 6379
- 结论：故障模拟后，哨兵节点自动发生切换，并且代码可自动寻找新的主机点，不影响数据写入。
四、权重选举恢复故障节点（手动将原主节点恢复成主节点）
1.设置其他节点的权重为0
redis-cli -h 10.0.0.52 -p 6379 CONFIG SET slave-priority 0
redis-cli -h 10.0.0.53 -p 6379 CONFIG SET slave-priority 0
2.手动发起重新选举
redis-cli -h 10.0.0.51 -p 26379 sentinel failover mymaster
3.验证选举结果:
redis-cli -h 10.0.0.51 -p 26379 Sentinel get-master-addr-by-name mymaster
1) "10.0.0.51"
2) "6379"
redis-cli -h 10.0.0.52 -p 26379 Sentinel get-master-addr-by-name mymaster
1) "10.0.0.51"
2) "6379"
redis-cli -h 10.0.0.53 -p 26379 Sentinel get-master-addr-by-name mymaster
1) "10.0.0.51"
2) "6379"
4.恢复哨兵节点权重，保证下次正常处理
redis-cli -h 10.0.0.52 -p 6379 CONFIG SET slave-priority 100
redis-cli -h 10.0.0.53 -p 6379 CONFIG SET slave-priority 100
5.观察切换结果是否符合预期
redis-cli -h 10.0.0.51 set kn vn
OK
redis-cli -h 10.0.0.52 -p 6379 CONFIG GET slave-priority
1) "slave-priority"
2) "100"
redis-cli -h 10.0.0.53 -p 6379 CONFIG GET slave-priority
1) "slave-priority"
2) "100"
五、Redis哨兵密码认证
说明：当Redis主节点开启了密码认证功能后，由于哨兵节点无法有效的知道Redis单节点的密码，因此哨兵节点无法正常启动
1.修改Redis单节点主配置文件
cat > /opt/redis_6379/conf/redis_6379.conf << EOF
### 以守护进程模式启动，在后台运行
daemonize yes
### 绑定的主机地址
bind 10.0.0.51 127.0.0.1
### 监听端口
port 6379
### pid文件和log文件的保存地址
pidfile "/opt/redis_6379/pid/redis_6379.pid"
logfile "/opt/redis_6379/logs/redis_6379.log"
### 设置数据库的数量，默认数据库为0
databases 16
### 指定本地持久化文件的文件名,默认是dump.rdb
dbfilename "redis_6379.rdb"
### 本地数据库的目录
dir "/data/redis_6379"
### 触发RBD持久化保存条件
#900S内有一个key生成触发RDB快照持久化
save 900 1
#300S内有十个key生成触发RDB快照持久化
save 300 10
#60S内有一万个key生成触发RDB快照持久化
save 60 10000
### 开启AOF独立日志持久化功能
##设置AOF独立日志名称
appendfilename "redis_6379.aof"
##AOF持久化功能开关
appendonly yes
##AOF重写时间设置--everysec每秒重写
appendfsync everysec
##AOF回写机制算法及触发条件，默认AOF文件大小超过64MB时触发
#auto-aof-rewrite-percentage 100
#auto-aof-rewrite-min-size 64mb
# Generated by CONFIG REWRITE（故障模拟主节点故障后自动同步的主从关系，故障恢复后无需处理）
slaveof 10.0.0.53 6379
### Redis主节点登陆密码
requirepass "123456"
###哨兵节点匹配主节点密码，要求与Redis单节点一致
masterauth "123456"
EOF
2.修改哨兵配置文件
vim /opt/redis_26379/conf/redis_26379.conf
bind 10.0.0.52 127.0.0.1
port 26379
daemonize yes
logfile "/opt/redis_26379/logs/redis_26379.log"
dir "/data/redis_26379"
sentinel myid da32db2c17d0718e208fd6db227ffb61d5f5dd74
sentinel monitor mymaster 10.0.0.51 6379 2
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 18000
# Generated by CONFIG REWRITE
sentinel config-epoch mymaster 2
sentinel leader-epoch mymaster 1
sentinel known-slave mymaster 10.0.0.53 6379
sentinel known-slave mymaster 10.0.0.52 6379
sentinel known-sentinel mymaster 10.0.0.53 26379 19e37e11882dcdc47ca8aa73a8207f4387e12254
sentinel known-sentinel mymaster 10.0.0.51 26379 79052b5f901edb979578856de3412ab2272a416c
sentinel current-epoch 2
sentinel auth-pass mymaster 123456
在哨兵配置文件添加此参数sentinel auth-pass mymaster 123456，代表哨兵识别主节点密码认证
3.注意事项
当我们修改完哨兵节点的配置文件后，重启哨兵节点，极有可能发现哨兵无法正常启动，说明哨兵管理系统中的配置文件信息发生改变，导致所有哨兵的节点信息无法互通共享，而信息互通共享的过程均是哨兵自主完成的，因此，在搭建哨兵过程如果Redis主节点中配置了密码认证功能，请在配置哨兵的配置文件中同时加入对应参数，建议不必开启redis单节点认证和哨兵认证功能
