redis 主从架构下如何才能做到高可用性？

什么是高可用？

做到高可用系统，保证大部分时间能正常提供服务，尽可能的 降低故障发生的次数 和 减少故障持续的时间。

学术的解释：可用性的高低 是使用 不可用时间 占 总时间 的比例来衡量。不可用时间是从故障发生到故障恢复的时间。比如，可用性 4 个 9 的系统（99.99%），它一年宕机时间不能超过53分钟（=3652460*(1-0.9999)）。

redis 不可用是什么？

系统挂掉，短时间内无法恢复起来

redis 怎么才能做到高可用？

通过主备切换，在很短的时间内恢复可用状态。redis 哨兵（sentinal node）功能提供了这种支持。

 

redis 哨兵架构的相关基础知识

sentinal 哨兵的介绍

哨兵是 redis 集群架构中非常重要的一个组件，主要功能如下

  • 集群监控：负责监控 redis master 和 slave 进程是否正常工作
  • 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员
  • 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上
  • 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址

哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作

  • 故障转移时，判断一个 master node 是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
  • 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的

sentinal 2 版本，相对于 sentinal 1 来说，让故障转移的机制和算法变得更加健壮和简单

哨兵的核心知识

  • 哨兵至少需要 3 个实例，来保证自己的健壮性
  • 哨兵 + redis 主从的部署架构，是不会保证数据零丢失的，只能保证 redis 集群的高可用性
  • 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练，可把生产数据拿过来进行容灾演练

为什么 redis 哨兵集群只有 2 个节点无法正常工作？

哨兵集群必须部署 2 个以上节点，如果哨兵集群仅仅部署了个 2 个哨兵实例，且 Configuration: quorum = 1 （只有一个节点投票通过就算选举成功）

+----+         +----+
| M1 |---------| R1 |
| S1 |         | S2 |
+----+         +----+

master 宕机，s1 和 s2 中只要有 1 个哨兵认为 master 宕机就可以切换，同时 s1 和 s2 中会选举出一个哨兵来执行故障转移

这个时候，需要 majority，也就是大多数哨兵都是运行的，2 个哨兵的 majority 就是 2（因为至少是 2 个节点以上，2 的 majority=2，3的 majority=2，5 的 majority=3，4 的 majority=2），2 个哨兵都运行着，就可以允许执行故障转移

但是如果整个 M1 和 S1 运行的机器宕机了，那么哨兵只有 1 个了，此时就没有 majority 来允许执行故障转移，虽然另外一台机器还有一个 R1，但是故障转移不会执行

经典的 3 节点哨兵集群

       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+

Configuration: quorum = 2，majority

如果 M1 所在机器宕机了，那么三个哨兵还剩下 2 个，S2 和 S3 可以一致认为 master 宕机，然后选举出一个来执行故障转移

同时 3 个哨兵的 majority 是 2，所以还剩下的 2 个哨兵运行着，就可以允许执行故障转移

 

redis 哨兵主备切换的数据丢失问题：异步复制、集群脑裂

异步复制导致的数据丢失

因为 master -> slave 的复制是异步的，所以可能有部分数据还没复制到 slave，master 就宕机了，此时这些部分数据就丢失了

脑裂导致的数据丢失

何为脑裂？如上图由于一个集群中的 master 恰好网络故障，导致与 sentinal 联系不上了，sentinal 把另一个 slave 提升为了 master。此时就存在两个 master了。

当我们发现的时候，停止掉其中的一个 master，手动切换成 slave，当它连接到提升后的 master 的时候，会开始同步数据，那么自己脑裂期间接收的写数据就被丢失了

解决异步复制和脑裂导致的数据丢失

主要通过两个配置参数来解决

  • min-slaves-to-write 1
  • min-slaves-max-lag 10

如上两个配置：要求至少有 1 个 slave，数据复制和同步的延迟不能超过 10 秒，如果超过 1 个 slave，数据复制和同步的延迟都超过了 10 秒钟，那么这个时候，master 就不会再接收任何请求了

此配置保证就算脑裂了，那么最多只能有 10 秒的数据丢失

上图说明了脑裂时，master 拒绝写数据的时候，client 可能额外需要做的事情，client 是说使用方，不是 redis 的东西。

下图也是一样的道理，有如上两个参数配置控制的话，脑裂时会减少数据的丢失

 

redis 哨兵的多个核心底层原理的深入解析（包含 slave 选举算法）

sdown 和 odown 转换机制

sdown 和 odown 是两种失败状态

  • sdown 是主观宕机

    一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机

  • odown 是客观宕机 如果 quorum 数量的哨兵都觉得一个 master 宕机了，那么就是客观宕机

sdown 达成的条件很简单，如果一个哨兵 ping 一个 master，超过了 is-master-down-after-milliseconds（在哨兵配置文件中配置的） 指定的毫秒数之后，就主观认为 master 宕机

sdown 到 odown 转换的条件很简单，如果一个哨兵在指定时间内，收到了 quorum 指定数量的其他哨兵也认为那个 master 是 sdown 了，那么就认为是 odown 了，客观认为 master 宕机

哨兵集群的自动发现机制

哨兵互相之间的发现，是通过 redis 的 pub/sub 系统实现的，每个哨兵都会往 __sentinel__:hello 这个 channel 里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在

每隔两秒钟，每个哨兵都会往自己监控的某个 master+slaves 对应的 __sentinel__:hello channel 里发送一个消息，内容是自己的 host、ip和 runid 还有对这个 master 的监控配置

每个哨兵也会去监听自己监控的每个 master+slaves 对应的 __sentinel__:hello channel，然后去感知到同样在监听这个 master+slaves 的其他哨兵的存在

每个哨兵还会跟其他哨兵交换对 master 的监控配置，互相进行监控配置的同步

slave 配置的自动纠正

哨兵会负责自动纠正 slave 的一些配置，比如 slave 如果要成为潜在的 master 候选人，哨兵会确保 slave 在复制现有 master 的数据; 如果 slave 连接到了一个错误的 master 上，比如故障转移之后，那么哨兵会确保它们连接到正确的 master 上

slave->master 选举算法

如果一个 master 被认为 odown 了，而且 majority 哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个 slave 来

会考虑 slave 的一些信息

  • 跟 master 断开连接的时长
  • slave 优先级
  • 复制 offset
  • run id

如果一个 slave 跟 master 断开连接已经超过了 down-after-milliseconds的 10 倍，外加 master 宕机的时长，那么 slave 就被认为不适合选举为 master，公式如下

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下来会对 slave 进行排序

  1. 按照 slave 优先级进行排序，slave-priority（redis 配置文件中的属性配置，默认为 100） 越低，优先级就越高
  2. 如果 slave priority 相同，那么看 replica offset，哪个 slave 复制了越多的数据，offset 越靠后，优先级就越高
  3. 如果上面两个条件都相同，那么选择一个 run id 比较小的那个 slave

quorum 和 majority

每次一个哨兵要做主备切换，首先需要 quorum 数量的哨兵认为主节点down，此时会从sdown升级为 odown，然后选举出一个哨兵来做切换，这个哨兵还得得到 majority 个数量哨兵的授权，才能正式执行切换

如果 quorum < majority，比如 5 个哨兵，majority=3，quorum=2，那么就 3 个哨兵授权就可以执行切换

但是如果 quorum >= majority，那么必须 quorum 数量的哨兵都授权；比如 5个哨兵，quorum=5，majority=3，那么必须 5 个哨兵都同意授权，才能执行切换

configuration epoch

哨兵会对一套 redis master+slave 进行监控，有相应的监控的配置

执行切换的那个哨兵，会从要切换到的新 master（salve->master）那里得到一个 configuration epoch，这就是一个 version 号，每次切换的 version 号都必须是唯一的

如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待 failover-timeout 时间，然后接替继续执行切换，此时会重新获取一个新的 configuration epoch，作为新的 version 号

configuraiton 传播

哨兵完成切换之后，会在自己本地更新生成最新的 master 配置，然后同步给其他的哨兵，就是通过之前说的 pub/sub 消息机制

这里之前的 version 号就很重要了，因为各种消息都是通过一个 channel 去发布和监听的，所以一个哨兵完成一次新的切换之后，新的 master 配置是跟着新的 version 号的

其他的哨兵都是根据版本号的大小来更新自己的 master 配置的

 

部署哨兵集群

如何操作部署哨兵集群，如何基于哨兵进行故障转移，还有一些企业级的配置方案

还是同一个 redis ，通过 redis-sentinel + sentinel 配置文件 启动的另一个程序

哨兵的配置文件

/usr/local/redis-3.2.8/sentinel.conf 是一个模板配置文件

主要的配置项目如下

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

可以看到如上的配置前缀一样，后面开始不一样了，是因为一套哨兵集群可以为多个 maser-slaves 的 redis 集群服务。

mymaster、resque 是每个 redis 主从集群分配一个逻辑的名称

上面的配置是一个最小的哨兵配置，就监控了两个 master node，如果发生了 master-slave 故障转移，或者新的哨兵进程加入哨兵集群，那么哨兵会自动更新自己的配置文件

 

sentinel monitor mymaster 127.0.0.1 6379 2

它的含义：sentinel monitor master-group-name hostname port quorum

配置了对哪一个 master 进行监控，并配置了 quorum 参数

quorum 的解释如下：

  • 至少多少个哨兵要一致同意，master 进程挂掉了，或者 slave 进程挂掉了，或者要启动一个故障转移操作
  • quorum 是用来识别故障的，真正执行故障转移的时候，还是要在哨兵集群执行选举，选举一个哨兵进程出来执行故障转移操作

假设有 5 个哨兵，quorum=2

那么如果 5 个哨兵中的 2 个都认为 master 挂掉了; 2 个哨兵中的一个就会做一个选举，选举一个哨兵出来，执行故障转移；如果 5 个哨兵中有 3 个哨兵都是运行的，那么故障转移就会被允许执行

 

sentinel down-after-milliseconds mymaster 60000

超过多少毫秒跟一个 redis 实例断了连接，哨兵就可能认为这个 redis 实例挂了

 

sentinel parallel-syncs mymaster 1

新的 master 切换之后，同时有多少个 slave 被切换到去连接新 master，重新做同步，数字越低，花费的时间越多

哨兵将 slave 升级为 master 后，一次操作能将几个 slave 切换到新的 master 上去。

假设你的 redis 是 1 个 master，4 个 slave：

master 宕机了，4 个 slave 中有 1 个切换成了 master，剩下 3 个 slave 就要挂到新的 master 上面去

这个时候，如果 parallel-syncs=1，那么 3 个 slave，一个一个地挂接到新的 master 上面去，1 个挂接完，而且从新的 master sync 完数据之后，再挂接下一个

如果 parallel-syncs 是 3，那么一次性就会把所有 slave 挂接到新的 master 上去

 

sentinel failover-timeout mymaster 180000

执行故障转移的 timeout 超时时长。从节点进行主备切换的时间超过该时长，其他从节点将会接替重新进行主备切换

 

 

sentinel 配置

在 eshop-cache03 上再部署一个 redis

使用 /usr/local/redis-3.2.8/sentinel.conf 作为目标，在 windows 上配置好三个机器的配置，再统一上传

以下文件除了 bind 的 ip 不一致外，其他的都是相同的

mkdir /etc/sentinal
mkdir -p /var/sentinal/5000

/etc/sentinel/5000.conf

------------------- eshop-cache01
port 5000
bind eshop-cache01
dir /var/sentinal/5000
sentinel monitor mymaster eshop-cache01 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

------------------- eshop-cache02
port 5000
bind eshop-cache02
dir /var/sentinal/5000
sentinel monitor mymaster eshop-cache01 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

------------------- eshop-cache03
port 5000
bind eshop-cache03
dir /var/sentinal/5000
sentinel monitor mymaster eshop-cache01 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

同步 linux 集群时间

yum install ntpdate

ntpdate -u ntp.api.bz

ntpdate ntp1.aliyun.com

启动哨兵进程

redis-sentinel /etc/sentinal/5000.conf

这种启动方式是通过前台启动的，所以可以能看到日志，一台一台启动就好

哨兵之间，互相会自动进行发现，用的就是 pub/sub，消息发布和订阅 channel 消息系统和机制

如果在配置文件 /etc/sentinal/5000.conf 中 bind没有把 127.0.0.1去掉，会导致123之间互相不能进行通信

------------------- eshop-cache01
1581:X 24 Mar 00:26:46.650 # Sentinel ID is 552d04d3c53079053d30942e339b1270615c1139
1581:X 24 Mar 00:26:46.650 # +monitor master mymaster 192.168.99.170 6379 quorum 2
1581:X 24 Mar 00:27:16.689 # +sdown slave 192.168.99.171:6379 192.168.99.171 6379 @ mymaster 192.168.99.170 6379

------------------- eshop-cache02
24665:X 24 Mar 00:25:10.597 # Sentinel ID is df47be63833763baccf4e42bbb94b6cf3bae7970
24665:X 24 Mar 00:25:10.597 # +monitor master mymaster 192.168.99.170 6379 quorum 2
24665:X 24 Mar 00:25:40.637 # +sdown master mymaster 192.168.99.170 6379

------------------- eshop-cache03
24426:X 24 Mar 00:25:18.997 # Sentinel ID is 86a7fdb94cfa1a138e002d876bbf3a7466fe7570
24426:X 24 Mar 00:25:18.997 # +monitor master mymaster 192.168.99.170 6379 quorum 2
24426:X 24 Mar 00:25:49.069 # +sdown master mymaster 192.168.99.170 6379

正常的日志如下

1052:X 24 Mar 00:44:22.609 # Sentinel ID is 507b3bc6e379011b990bda44b73221b8f7b305c1
1052:X 24 Mar 00:44:22.609 # +monitor master mymaster 192.168.99.170 6379 quorum 2
1052:X 24 Mar 00:44:33.454 * +sentinel sentinel a1cd62295346683bcd8f8b388ac64e83897a13dd 192.168.99.172 5000 @ mymaster 192.168.99.170 6379
1052:X 24 Mar 00:45:27.155 * +sentinel sentinel d7a9812a3f905d07df46986f1b21388a16df39b4 192.168.99.171 5000 @ mymaster 192.168.99.170 6379

检查哨兵状态

# 连接指定哨兵
redis-cli -h eshop-cache01 -p 5000
# 查看监控的 redis 集群配置
sentinel master mymaster
# 查看集群下的 slave node 信息
sentinel slaves mymaster
# 查看监控 mymaster 集群的所有哨兵
sentinel sentinels mymaster

# 查看 mymaster 集群的 master 信息
sentinel get-master-addr-by-name mymaster

# 如下的 master 是 170.其他命令数据都很多，只有这个只有2行信息
eshop-cache03:5000> sentinel get-master-addr-by-name mymaster
1) "192.168.99.170"
2) "6379"

 

 

哨兵节点管理及高可用 redis 集群的容灾演练

哨兵节点的增加和删除

增加 sentinal ,会互相自动发现，发现之后就把该哨兵信息添加到自己节点信息中了，这个可以通过一个实验来证明：

  1. 上一章启动了 3 台 sentinal，

  2. 在机器重启之后，只启动其中的一台机器

    [root@eshop-cache03 ~]# redis-sentinel /etc/sentinal/5000.conf

  3. 连接上查看 sentinals 信息

    redis-cli -p 5000 -h eshop-cache03

eshop-cache03:5000> sentinel sentinels mymaster
会发现出现了 01 和 02 的信息，但是此时 01 和 02 并没有启动

  4. 执行 SENTINEL RESET * 命令

    执行之后，再次查看 sentinel sentinels mymaster 信息，会发现变成空的了，消失了

删除 sentinal 的步骤

  1. 停止 sentinal 进程

  2. SENTINEL RESET * （重要）

    在所有存活的 sentinal 上执行，清理所有的 master 状态

  3. SENTINEL MASTER mastername

    在所有存活的 sentinal 上执行，查看自己对 mastername 的集群信息是否与其他 sentinal 一致

redis slave 的永久下线

让 master 摘除某个已经下线的 slave：SENTINEL RESET mastername，在所有的哨兵上面执行，相当于重置检查

slave 切换为 Master 的优先级

slave->master 选举优先级：slave-priority，值越小优先级越高

基于哨兵集群架构下的安全认证

每个 slave 都有可能切换成 master，所以每个实例都要配置两个指令

master 上启用安全认证，requirepass master 连接口令，masterauth

在 sentinal 的配置文件里面配置密码： sentinel auth-pass <master-group-name> <pass>

容灾演练

通过哨兵看一下当前的 master：SENTINEL get-master-addr-by-name mymaster

这里的 master 在 02 上面，直接 kill 掉 master；查看 哨兵的日志变化

[root@eshop-cache02 ~]# ps -ef | grep redis
root       960     1  2 01:00 ?        00:00:42 /usr/local/bin/redis-server 127.0.0.1:6379      
root      1049  1009  3 01:21 pts/0    00:00:26 redis-sentinel eshop-cache02:5000 [sentinel]
root      1068  1054  0 01:33 pts/1    00:00:00 grep redis
[root@eshop-cache02 ~]# kill 960

等待一会，该配置时间 sentinel down-after-milliseconds mymaster 30000 30 秒后， 可以看到哨兵日志发生了变化

注意：下面的日志是在切换 master 的哨兵上看到的。非切换的哨兵日志上不会有这么多信息

1037:X 24 Mar 01:55:05.525 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1037:X 24 Mar 01:55:05.525 # Sentinel ID is 507b3bc6e379011b990bda44b73221b8f7b305c1
1037:X 24 Mar 01:55:05.525 # +monitor master mymaster 192.168.99.171 6379 quorum 2
1037:X 24 Mar 01:55:15.551 * +convert-to-slave slave 192.168.99.170:6379 192.168.99.170 6379 @ mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:07.924 # +sdown master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.013 # +odown master mymaster 192.168.99.171 6379 #quorum 2/2
1037:X 24 Mar 01:57:08.013 # +new-epoch 3
1037:X 24 Mar 01:57:08.013 # +try-failover master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.027 # +vote-for-leader 507b3bc6e379011b990bda44b73221b8f7b305c1 3
1037:X 24 Mar 01:57:08.138 # a1cd62295346683bcd8f8b388ac64e83897a13dd voted for a1cd62295346683bcd8f8b388ac64e83897a13dd 3
1037:X 24 Mar 01:57:08.152 # d7a9812a3f905d07df46986f1b21388a16df39b4 voted for 507b3bc6e379011b990bda44b73221b8f7b305c1 3
1037:X 24 Mar 01:57:08.207 # +elected-leader master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.207 # +failover-state-select-slave master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.291 # +selected-slave slave 192.168.99.170:6379 192.168.99.170 6379 @ mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.291 * +failover-state-send-slaveof-noone slave 192.168.99.170:6379 192.168.99.170 6379 @ mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.351 * +failover-state-wait-promotion slave 192.168.99.170:6379 192.168.99.170 6379 @ mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.947 # +promoted-slave slave 192.168.99.170:6379 192.168.99.170 6379 @ mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.947 # +failover-state-reconf-slaves master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.979 # +failover-end master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.982 # +switch-master mymaster 192.168.99.171 6379 192.168.99.170 6379
1037:X 24 Mar 01:57:08.983 * +slave slave 192.168.99.171:6379 192.168.99.171 6379 @ mymaster 192.168.99.170 6379
1037:X 24 Mar 01:57:39.038 # +sdown slave 192.168.99.171:6379 192.168.99.171 6379 @ mymaster 192.168.99.170 6379
  1. 三个哨兵进程都认为 master 是 sdown 了
  2. 超过 quorum 指定的哨兵进程都认为 sdown 之后，就变为 odown
  3. 哨兵 1 是被选举为要执行后续的主备切换的那个哨兵
  4. 哨兵 1 去新的 master（slave）获取了一个新的 config version
  5. 尝试执行 failover
  6. 投票选举出一个 slave 区切换成 master，每个哨兵都会执行一次投票
  7. 让 salve，slaveof noone，不让它去做任何节点的 slave 了; 把 slave 提拔成 master; 旧的 master 认为不再是 master 了
  8. 哨兵就自动认为之前的 171:6379 变成了 slave 了，190:6379 变成了 master 了
  9. 哨兵去探查了一下 171:6379 这个 salve 的状态，认为它 sdown 了

此时再查看 /etc/sentinal/5000.conf 中的配置文件的时候，会发现一些配置跟着改变了，比如

# 最开始我们配置的是 hostname，这里被更新成了 ip
sentinel monitor mymaster 192.168.99.170 6379 2

如果哨兵的majority都存活着，那么就会执行主备切换操作

通过哨兵看一下master：SENTINEL get-master-addr-by-name mymaster


尝试连接一下新的master

将旧的 master 重新启动，查看变化

[root@eshop-cache02 ~]# /etc/init.d/redis_6379 start
/var/run/redis_6379.pid exists, process is already running or crashed
[root@eshop-cache02 ~]# rm -rf /var/run/redis_6379.pid
[root@eshop-cache02 ~]# /etc/init.d/redis_6379 start
Starting Redis server...
[root@eshop-cache02 ~]# redis-cli
127.0.0.1:6379> info replication
# Replication
role:slave      // 这里，重启之后变成了 slave
master_host:192.168.99.170
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:1160
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

看看之前执行故障转移的哨兵日志

# sdown 状态变成了减号
1037:X 24 Mar 02:09:43.363 # -sdown slave 192.168.99.171:6379 192.168.99.171 6379 @ mymaster 192.168.99.170 6379
# 并且转换成了 slave
1037:X 24 Mar 02:09:53.373 * +convert-to-slave slave 192.168.99.171:6379 192.168.99.171 6379 @ mymaster 192.168.99.170 6379

小结：

  1. 手动杀掉master
  2. 哨兵能否执行主备切换，将 slave 切换为 master
  3. 哨兵完成主备切换后，新的 master 能否使用
  4. 故障恢复，将旧的 master 重新启动
  5. 哨兵能否自动将旧的 master 变为 slave，挂接到新的 master 上面去，而且也是可以使用的

哨兵的生产环境部署

在 /etc/sentinal/5000.conf 中增加两个配置

# 后台启动
daemonize yes
# 把日志打印到指定位置
logfile /var/log/sentinal/5000/sentinal.log

记得要把目录创建好

mkdir -p /var/log/sentinal/5000

 

参考：
https://zq99299.github.io/note-book/cache-pdp/redis/020.html