原文:https://blog.csdn.net/chenyang_wei/article/details/127846656
在 Redis 主从复制模式中,因为系统不具备自动恢复的功能,所以当主服务器(master)宕机后,需要手动把一台从服务器(slave)切换为主服务器。在这个过程中,不仅需要人为干预,而且还会造成一段时间内服务器处于不可用状态,同时数据安全性也得不到保障,因此主从模式的可用性较低,不适用于线上生产环境。
Redis 官方推荐一种高可用方案,也就是 Redis Sentinel 哨兵模式,它弥补了主从模式的不足。Sentinel 通过监控的方式获取主机的工作状态是否正常,当主机发生故障时, Sentinel 会自动进行 Failover(即故障转移),并将其监控的从机提升主服务器(master),从而保证了系统的高可用性。
哨兵模式是一种特殊的模式,Redis 为其提供了专属的哨兵命令,它是一个独立的进程,能够独立运行。
哨兵主要有两个重要作用:
1、哨兵节点会以每秒一次的频率对每个 Redis 节点发送PING命令,并通过 Redis 节点的回复来判断其运行状态;
2、当哨兵监测到主服务器发生故障时,会自动在从节点中选择一台将机器,并其提升为主服务器,然后使用 PubSub 发布订阅模式,通知其他的从节点,修改配置文件,跟随新的主服务器。
在实际生产情况中,Redis Sentinel 是集群的高可用的保障,为避免 Sentinel 发生意外,它一般是由 3~5 个节点组成,这样就算挂了个别节点,该集群仍然可以正常运转。
本例环境配置:
master : 127.0.0.1 6380
slave1:127.0.0.1 6381
slave2:127.0.0.1 6382
sentinel1:127.0.0.1 16380
sentinel2:127.0.0.1 16381
sentinel3:127.0.0.1 16382
一、Redis集群配置
可参考:中间件:Redis-x64-5.0.14.1集群主从复制(Win10)
二、哨兵Sentinel配置
1、给master 6380中增加哨兵配置文件 sentinel.conf
哨兵全部配置主服务器信息,因为master有slave信息
#当前Sentinel服务运行端口
port 16380
# 哨兵监听的主服务器
sentinel monitor mymaster 127.0.0.1 6380 2
# 3s内mymaster无响应,则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来,则启动failover
sentinel failover-timeout mymaster 10000
# 执行故障转移时, 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
2、同样给从服务 6381、6382下增加 sentinel.conf
#当前Sentinel服务运行端口
port 16381
# 哨兵监听的主服务器
sentinel monitor mymaster 127.0.0.1 6380 2
# 3s内mymaster无响应,则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来,则启动failover
sentinel failover-timeout mymaster 10000
# 执行故障转移时, 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
#当前Sentinel服务运行端口
port 16382
# 哨兵监听的主服务器
sentinel monitor mymaster 127.0.0.1 6380 2
# 3s内mymaster无响应,则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来,则启动failover
sentinel failover-timeout mymaster 10000
# 执行故障转移时, 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
3、启动集群
先启动master,再启动slave 6381、6382;启动可参考:中间件:Redis-x64-5.0.14.1集群主从复制(Win10)
4、启动哨兵
三个哨兵启用后,可以看见生成三个不同的 Sentinel ID
5、集群状态
三、测试
1、测试主机master 6380宕机
通过选票,6382成为master,6381中的master变成 6382。
2、停机的原master 6380重启
6380仍是从服务器,6382是master;6380不会再变回master。
3、slave 6381宕机
6382中可以看到只剩6380一个从机
重启6381 slave,6381回归关闭前状态
四、其他
1、从机配置命令:slave [master ip] [master port]
2、哨兵监听的主服务器:sentinel monitor [master名称(可以自定义)] [ip] [port] [通过票数]
master宕机后,从机投票通过设定的 通过票数 后认定master宕机,设定slave为master。
3、sentinel <选项的名字> <主服务器的名字> <选项的值>
down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数;
如果服务器在给定的毫秒数之内, 没有返回 Sentinel 发送的 PING 命令的回复, 或者返回一个错误, 那么 Sentinel 将这个服务器标记为主观下线(subjectively down,简称 SDOWN )。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移: 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后, 服务器才会被标记为客观下线(objectively down, 简称 ODOWN ), 这时自动故障迁移才会执行。将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
parallel-syncs 选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长。
4、Windows cmd启动redis:redis-server.exe redis.windows.conf;
5、Windows cmd启动哨兵:redis-server.exe sentinel.conf –sentinel;
6、Windows cmd redis cli:redis-cli.exe -h IP -p 端口;
7、Windows cmd redis cli查看redis状态信息:info replication;
————————————————
版权声明:本文为CSDN博主「我也不清楚」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/chenyang_wei/article/details/127846656