Redis 主从复制和哨兵模式

一、概念

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为主节点**（master/leader）** ，后者称为从节点**（slave/follower）** 。数据的复制是单向的，只能由主节点到从节点。Master 以写为主，Slave以读为主。

默认情况下，每台 Redis 服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

1.1 主要作用

1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3、负载均衡 ：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写 Redis 数据时应用连接主节点，读 Redis 数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis服务器的并发量。

4、高可用基石 ：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是 Redis高可用的基础。

1.2 单台瓶颈

一般来说，要将 Redis 运用于工程项目中，只使用一台 Redis是万万不能的，原因如下：

1、 从结构上，单个 Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大。

2、 从容量上，单个 Redis 服务器内存容量有限，就算一台 Redis 服务器内存容量为 256G ，也不能将所有内存用作 Redis 存储内存，一般来说，单台 Redis 最大使用内存不应该超过 20G。

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"多读少写"。对于这种场景，我们可以使如下这种架构：

主从复制，读写分离 。**80%**的情况下都是在进行读操作，减缓服务器的压力，在架构中经常使用。（最低需要一主二从）

二、环境配置

2.1 查看信息

通过输入 info replication 命令可以查看当前 redis库的信息，如下所示

127.0.0.1:6379> info replication                           # 查看当前库的信息
# Replication
role:master                                                # 当前角色 master
connected_slaves:0                                         # 没有从机
master_failover_state:no-failover
master_replid:54a28e688e4551d9699b335c17a0deb9c8d06467
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

2.2 复制文件

复制 redis 的配置文件，复制三份，如下所示

[root@localhost myredis]# ls
redis.conf
[root@localhost myredis]# cp redis.conf redis79.conf
[root@localhost myredis]# cp redis.conf redis80.conf
[root@localhost myredis]# cp redis.conf redis81.conf
[root@localhost myredis]# ls
redis79.conf  redis80.conf  redis81.conf  redis.conf

2.3 修改文件

需要修改上面复制的三个配置文件信息，需要修改的内容如下所示：

# 三份文件的端口号分别为 6379、6380、6381
port 6379

# pid 名字
pidfile "/var/run/redis_6379.pid"

# log 文件名字
logfile "6379.log"

# dump.pid 的名字
dbfilename "dump6379.rdb"

2.4 启动测试

上面都配置完毕后，3 个服务通过3 个不同的配置文件开启，我们的准备环境就 OK 了！

# 第一台服务器启动
[root@localhost bin]# redis-server myredis/redis79.conf 
[root@localhost bin]# ls
6379.log  appendonlydir  dump.rdb  myredis  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis-sentinel  redis-server
[root@localhost bin]# redis-cli -p 6379
127.0.0.1:6379> 

# 第二台服务器启动
[root@localhost bin]# redis-server myredis/redis80.conf 
[root@localhost bin]# ls
6379.log  6380.log  appendonlydir  dump.rdb  myredis  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis-sentinel  redis-server
[root@localhost bin]# redis-cli -p 6380
127.0.0.1:6380> 

# 第三台服务器启动
[root@localhost bin]# redis-server myredis/redis81.conf 
[root@localhost bin]# ls
6379.log  6380.log  6381.log  appendonlydir  dump.rdb  myredis  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis-sentinel  redis-server
[root@localhost bin]# redis-cli -p 6381
127.0.0.1:6381> 

查看 redis的进程，查看是否完全启动成功。 如下所示：

[root@localhost bin]# ps -ef | grep redis
root      62142      1  0 00:33 ?        00:00:13 redis-server 127.0.0.1:6379
root      63363      1  0 01:54 ?        00:00:00 redis-server 127.0.0.1:6380
root      63376      1  0 01:54 ?        00:00:00 redis-server 127.0.0.1:6381
root      63382  56368  0 01:54 pts/2    00:00:00 redis-cli -p 6379
root      63391  57550  0 01:55 pts/3    00:00:00 redis-cli -p 6380
root      63392  63102  0 01:55 pts/1    00:00:00 redis-cli -p 6381
root      63394  63141  0 01:55 pts/4    00:00:00 grep --color=auto redis

三、一主二从

3.1 节点信息查看

三台 redis 服务器，默认都是 Master节点，如下图所示

# 第一台服务器查看节点信息
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:54a28e688e4551d9699b335c17a0deb9c8d06467
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# 第二台服务器查看节点信息
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:5fa97c2e9e96b6ba5bc275a7a1c8c9126112ff03
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# 第三台服务器查看节点信息
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:2187b763138a4c5e77b58c77d4702f4f6132eaa2
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

3.2 配置从机

使用 slaveof 命令使 master节点变为从节点。

# 使用 slaveof 命令使主节点变为从节点
127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
(1.35s)

# 再次查看当前的节点信息，发现变为了从节点
127.0.0.1:6380> info replication
# Replication
role:slave               # 当前的角色
master_host:127.0.0.1    # 可以看到主机信息
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_read_repl_offset:0
slave_repl_offset:0
master_link_down_since_seconds:-1
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:5fa97c2e9e96b6ba5bc275a7a1c8c9126112ff03
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0


# 使用 slaveof 命令使主节点变为从节点
127.0.0.1:6381> slaveof 127.0.0.1 6379
OK
# 再次查看当前的节点信息，发现变为了从节点
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:168
slave_repl_offset:168
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:6ccdf51ea4dec3fbabc8fd94fdfdb4cf00856171
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:168
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:169
repl_backlog_histlen:0


# 在主机上重新查看节点的信息，发现多了两个从机的信息
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=238,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=238,lag=0
master_failover_state:no-failover
master_replid:6ccdf51ea4dec3fbabc8fd94fdfdb4cf00856171
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:238
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:238

3.3 真实的主从配置

真实的主从配置应该是在配置文件中配置的，只有在配置文件中配置才是永久的，我们上面使用命令的配置是暂时的，一旦某一个节点关机，那么也就失去了主从的配置。

3.4 主从节点测试

3.4.1 主从节点特点

主节点可以写 ，从节点不可以写只能读。主节点中的所有信息和数据，都会自动被从节点保存。

# 主节点可以进行写操作
127.0.0.1:6379> set k1 v1
OK

# 从节点1可以查看所有的信息
# 但是无法进行写的操作
127.0.0.1:6380> clear
127.0.0.1:6380> keys *
1) "k1"
127.0.0.1:6380> get k1
"v1"
127.0.0.1:6380> set k2 v2
(error) READONLY You can t write against a read only replica.

# 从节点2可以查看所有的信息
127.0.0.1:6381> get k1
"v1"

3.4.2 主节点重连测试

主机断开连接，从机依旧连接到主机，就是无法进行写操作了。这个时候如果主机回来了，从机依旧可以直接获取到主机写的信息。

# 首先关闭主机
127.0.0.1:6379> shutdown
not connected> exit
# 重新开启主机并 set 值
[root@localhost bin]# redis-server myredis/redis79.conf 
[root@localhost bin]# redis-cli -p 6379
127.0.0.1:6379> set k2 v2
OK

# 可以在从机获取到主机 set 的值
127.0.0.1:6380> get k2
"v2"

3.4.2 从节点重连测试

如果使用命令行来配置的主从，这个时候如果从机重启了，从机就会变回主机。只要通过命令的方式再变回为从机，从机立马就可以获取到主机的所有值

127.0.0.1:6381> info replication
# Replication
role:slave                          # 当前的角色是从机
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_read_repl_offset:528
slave_repl_offset:528
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:528
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:528

# 进行重启操作
127.0.0.1:6381> shutdown
not connected> exit
[root@localhost bin]# redis-server myredis/redis81.conf 
[root@localhost bin]# redis-cli -p 6381
127.0.0.1:6381> info replication
# Replication
role:master                         # 当前的角色是主机            
connected_slaves:0
master_failover_state:no-failover
master_replid:2bd7531932a454bc6c492f04a1a96abd4a897855
master_replid2:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_repl_offset:542
second_repl_offset:543
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:543
repl_backlog_histlen:0

3.5 复制原理

Slave 启动成功连接到 master 后会向 master 发送一个 sync命令。

master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master 将传送整个数据文件到 slave，并完成一次完全同步。

全量复制 ：而 slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制 ：Master 继续将新的所有收集到的修改命令依次传给 slave ，完成同步但是只要是重新连接 master，一次完全同步（全量复制）将被自动执行，我们的数据一定可以在从机中看到。

3.6 层层链路

上一个 Slave 可以是下一个 slave 和 Master ，Slave 同样可以接收其他 slaves 的连接和同步请求，那么该 slave 作为了链条中下一个的 master ，可以有效减轻 master的写压力！

# 配置客户端3变为客户端2的从机
127.0.0.1:6381> slaveof 127.0.0.1 6380
OK
# 查看当前的从机的信息
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_read_repl_offset:5386
slave_repl_offset:5386
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5386
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:5359
repl_backlog_histlen:28


# 此时查看客户端1的节点信息
# 此时的客户端1只剩下6380一个节点
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=5526,lag=0
master_failover_state:no-failover
master_replid:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5526
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:5526


# 查看下最特殊的客户端2
# 我们发现他还是一个从节点，依旧无法进行写入操作
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_read_repl_offset:5610
slave_repl_offset:5610
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=5610,lag=0
master_failover_state:no-failover
master_replid:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5610
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:5610


# 客户端1进行写入
127.0.0.1:6379> set k6 v6
OK

# 客户端2可以查询到
127.0.0.1:6380> get k6
"v6"

# 客户端3也可以查询到
127.0.0.1:6381> get k6
"v6"

3.7 谋朝篡位

一主二从的情况下，如果主机断了，从机可以使用命令 SLAVEOF NO ONE 将自己改为主机！这个时候其余的从机链接到这个节点。对一个从属服务器执行命令SLAVEOF NO ONE 将使得这个从属服务器关闭复制功能，并从从属服务器转变回主服务器，原来同步所得的数据集不会被丢弃。

即使主机再回来，也只是一个光杆司令了，从机为了正常使用跑到了新的主机上！

# 断开主节点
127.0.0.1:6379> shutdown
not connected> exit

# 从节点执行命令，发现自己变为了主节点
127.0.0.1:6380> slaveof no one
OK
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=6045,lag=1
master_failover_state:no-failover
master_replid:6876480e76af2999855e6571bc7de430a0cc4f02
master_replid2:e33ec29ec8de6e256c43a64b46057d2a81c83182
master_repl_offset:6045
second_repl_offset:6018
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:6045

四、哨兵模式

4.1 概念

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis 从2.8 开始正式提供了 Sentinel（哨兵） 架构来解决这个问题。

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

哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程 ，作为进程，它会独立运行。原理是哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。

这里的哨兵有两个作用：

1、 通过发送命令，让 Redis服务器返回监控其运行状态，包括主服务器和从服务器。

2、 当哨兵监测到 master 宕机，会自动将 slave 切换成 master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对 Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线 。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

4.2 测试

我们目前的状态是一主二从，下面的测试是基于这个状态。

4.2.1 创建 sentinel 的配置文件

# 创建 sentinel.conf 文件
[root@localhost myredis]# ls
redis79.conf  redis80.conf  redis81.conf  redis.conf
[root@localhost myredis]# vim sentinel.conf
[root@localhost myredis]# ls
redis79.conf  redis80.conf  redis81.conf  redis.conf  sentinel.conf


# sentinel.conf 内容如下所示
# sentinel monitor 被监控的名称 ip port 1
# 上面最后一个数字1，表示主机挂掉后 slave 投票看让谁接替成为主机，得票数多少后成为主机
sentinel monitor myredis 127.0.0.1 6379 1

4.2.2 启动 sentinel 进程

# 输入命令启动 sentinel
[root@localhost bin]# redis-sentinel myredis/sentinel.conf 
68012:X 30 Aug 2023 19:44:25.745 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
68012:X 30 Aug 2023 19:44:25.745 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
68012:X 30 Aug 2023 19:44:25.745 * Redis version=7.2.0, bits=64, commit=00000000, modified=0, pid=68012, just started
68012:X 30 Aug 2023 19:44:25.745 * Configuration loaded
68012:X 30 Aug 2023 19:44:25.745 * Increased maximum number of open files to 10032 (it was originally set to 1024).
68012:X 30 Aug 2023 19:44:25.745 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 7.2.0 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 68012
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

68012:X 30 Aug 2023 19:44:25.746 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
68012:X 30 Aug 2023 19:44:27.425 * Sentinel new configuration saved on disk
68012:X 30 Aug 2023 19:44:27.425 * Sentinel ID is 7d49ccc2c94c126d96432b3ee075b37bbc4e6ba4
68012:X 30 Aug 2023 19:44:27.443 # +monitor master myredis 127.0.0.1 6379 quorum 1
68012:X 30 Aug 2023 19:44:27.519 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
68012:X 30 Aug 2023 19:44:27.522 * Sentinel new configuration saved on disk
68012:X 30 Aug 2023 19:44:27.522 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
68012:X 30 Aug 2023 19:44:27.524 * Sentinel new configuration saved on disk

4.2.3 断开测试

如果主节点断开了，这个时候就会从从机中随机选择一个服务器作为主节点（这里面有一个投票算法）

如果主机此时回来了，只能归并到新的主机下，当作从机，这就是哨兵模式的规则。

# 关闭主节点
127.0.0.1:6379> shutdown
(0.98s)
not connected> exit


# 查看从节点1的信息
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:25095
slave_repl_offset:25095
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:a7529ac9efada9ef3cabd4ce80c622b12fb39b69
master_replid2:7331d8dbfc77c3fe3f75d7b68df331925cbb5f49
master_repl_offset:25095
second_repl_offset:13761
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:6018
repl_backlog_histlen:19078


# 查看从节点2的信息，发现他变为了主节点
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=26165,lag=1
master_failover_state:no-failover
master_replid:a7529ac9efada9ef3cabd4ce80c622b12fb39b69
master_replid2:7331d8dbfc77c3fe3f75d7b68df331925cbb5f49
master_repl_offset:26165
second_repl_offset:13761
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:6032
repl_backlog_histlen:20134

4.3 优点

**1、**哨兵集群模式是基于主从模式的，所有主从的优点，哨兵模式同样具有。

**2、**主从可以切换，故障可以转移，系统可用性更好。

**3、**哨兵模式是主从模式的升级，系统更健壮，可用性更高。

4.4 缺点

1、Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

**2、**实现哨兵模式的配置也不简单，甚至可以说有些繁琐

4.5 哨兵配置说明

# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379

# 哨兵sentinel的工作目录
dir /tmp

# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd

# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1

# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
# 1. 同一个sentinel对同一个master两次failover之间的间隔时间。
# 2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
# 3.当想要取消一个正在进行的failover所需要的时间。
# 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

# SCRIPTS EXECUTION
# 配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
# 对于脚本的运行结果有以下规则：
# 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
# 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
# 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
# 一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
# 通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等
# 等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常
# 运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果
# sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
# 通知脚本
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh

# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是"failover",
# <role>是"leader"或者"observer"中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh