目录
从上一篇的一主二从改进为哨兵模式
哨兵模式
能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库
在原来的一主二仆模式下进行改造
进入到目录
cd /opt/redis/master_slave
哨兵配置
新建 sentinel.conf 文件,内容如下
sentinel monitor mymaster 127.0.0.1 6379 1
其中mymaster为监控对象起的服务器名称, 1 为至少有多少个哨兵同意迁移的数量。

启动哨兵
redis-sentinel sentinel.conf
测试哨兵
当主机宕机,会从从机中选择一个作为新的主机,根据优先级slave-properity, 原主机重启后会成为从机
关闭主节点
redis-cli -p 6379
shutdown


+sdown :主观下线(Subjective Down) 当前这个哨兵进程,单方面认为 master(mymaster,127.0.0.1:6379)挂了。只是单个哨兵的判断,不代表集群认定主节点故障。
+odown :客观下线(Objective Down) 多个哨兵达成共识,判定主节点真的宕机,可以触发故障转移。
quorum 1/1:法定票数 1,当前达成投票 1。哨兵配置
quorum=1,单哨兵架构。只要这一个哨兵认为主节点挂了,直接进入客观下线,开始选主。生产环境强烈不建议 quorum=1,单点哨兵本身就是单点故障!
进入到 6381
redis-cli -p 6381
info replication

可以看到 6381已经切换为master节点
当前问题
- 哨兵模式,配置了一台哨兵,生产环境起码要配置3台,防止哨兵挂了,高可用直接失效
- 容量不够,后续如何扩容,是否方便
- 并发写操作,如何分摊
集群。。。