云服务器redis主从复制-哨兵模式

从上一篇的一主二从改进为哨兵模式

云服务器redis主从复制-一主二仆-CSDN博客主机数据更新后，自动同步到备机Master以写为主，Slave以读为主目的读写分离，性能扩展容灾快速恢复1 一个redis服务作为主机,主要负责写操作2 两个redis服务作为从机,主要负责读操作3 从机自动从主机同步数据下来4 从机主动找主机,而主机不会找从机！！注意：生产环境，主从复制每个服务都在不同的机器上，这里使用一台机器不同端口模拟搭建真是环境。https://blog.csdn.net/guo13313/article/details/167179189?spm=1001.2014.3001.5502

哨兵模式

能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

在原来的一主二仆模式下进行改造

进入到目录

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台，防止哨兵挂了，高可用直接失效

容量不够，后续如何扩容，是否方便

并发写操作，如何分摊

集群。。。