Redis主从复制

概念：

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

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

点击并拖拽以移动

主从复制的作用主要包括：

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写redis数据时应用连接主节点，读redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个读节点分担读负载，可以大大提高redis的并发量。
高可用（集群）基石：除了上述的作用以外，主从复制还是哨兵模式和集群能够实施的基础，因此说主从复制是redis高可用的基础。

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

从结构上：单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；
从容量上：单个Redis的内存容量有限，就算一台redis服务器的内存容量是256G，也不能将所有的内存用作Redis的存储内存，一般来说，单台Redis最大使用内存不应该超过20G；

环境配置

只配置从库，不用配置主库（因为默认情况下，每台redis服务器都是主节点）！

查看当前服务器库信息如下：

127.0.0.1:6379> info replication #查看当前库的信息
# Replication
role:master     #角色 master
connected_slaves:0  #连接的从机数
master_replid:02e55856e4daafc3fd702f2c47002edcaa3e4358
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:6379>

单机多服务🎈:在单机上通过开启多个redis服务来伪造多台redis服务器。

1.复制三份启动文件

[root@shiyaochang sconfig]# cp redis.conf redis79.conf
[root@shiyaochang sconfig]# cp redis.conf redis80.conf
[root@shiyaochang sconfig]# cp redis.conf redis81.conf
[root@shiyaochang sconfig]# ls
redis79.conf  redis80.conf  redis81.conf  redis.conf

2.修改以下内容（以redis80.conf为例）：

端口：port 6380
pidfile /var/run/redis_6380.pid
logfile “6380.log”
dbfilename dump80.rdb

[root@shiyaochang sconfig]# vim redis79.conf 
[root@shiyaochang sconfig]# vim redis80.conf 
[root@shiyaochang sconfig]# vim redis81.conf

3.同时开启三个redis服务：

[root@shiyaochang bin]# redis-server sconfig/redis79.conf 
[root@shiyaochang bin]# redis-server sconfig/redis80.conf 
[root@shiyaochang bin]# redis-server sconfig/redis81.conf 
[root@shiyaochang bin]# ps -aux|grep redis  查看发现三个redis服务都已开启
root     13988  0.0  0.1 162380  2512 ?        Ssl  16:10   0:00 redis-server *:6379
root     14006  0.0  0.1 162380  2508 ?        Ssl  16:10   0:00 redis-server *:6380
root     14026  0.0  0.1 162380  2512 ?        Ssl  16:10   0:00 redis-server *:6381
root     14041  0.0  0.0 112816   976 pts/0    R+   16:10   0:00 grep --color=auto redis
[root@shiyaochang bin]# ls
6379.log  6381.log          mcrypt    redis-benchmark  redis-check-rdb  redis-sentinel  sconfig
6380.log  libmcrypt-config  mdecrypt  redis-check-aof  redis-cli        redis-server
[root@shiyaochang bin]#

4.一主二从集群搭建

通过命令（ slaveof）

主机我们使用端口为6379的端口，从机使用端口为6380和6381的服务。

Client窗口1（从机6380）：

[root@shiyaochang bin]# redis-cli -p 6380 #连接端口号为6380的redis服务
127.0.0.1:6380> slaveof 127.0.0.1 6379    ##--将当前服务转变为指定服务器的从属服务
OK
127.0.0.1:6380> info replication ## 查看库信息
# Replication
role:slave  #角色变为从机
master_host:127.0.0.1 #主机ip
master_port:6379      #主机服务端口
master_link_status:up
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:1
master_link_down_since_seconds:1613205682
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2100cac94e72661bdc3711ebc5c5ac9aac691649
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>

注意：如果出现master_link_status:down 提示，显示主机是down的状态，说明主机没有从机挂载。这可能是因为主机配置了的密码requirepass的原因，需要对从机slave的配置文件（redis6379.conf）进行如下修改：

masterauth  主机密码   #指定主机密码

Client窗口2（从机6381）：

[root@shiyaochang bin]# redis-cli -p 6381  #连接端口号为6381的redis服务
127.0.0.1:6381> info replication ## 查看库信息
# Replication
role:master #角色 主机
connected_slaves:0
master_replid:dd8bc54994ca8c0c112b9d99d668f34c31cee21f
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> 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_repl_offset:1
master_link_down_since_seconds:1613206237
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:dd8bc54994ca8c0c112b9d99d668f34c31cee21f
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>

Client窗口3（主机6379）：

[root@shiyaochang bin]# redis-cli -p 6379  #连接端口号为6379的redis服务
127.0.0.1:6379> info replication ## 查看库信息
# Replication
role:master
connected_slaves:2 #连接的从机数
slave0:ip=127.0.0.1,port=6380,state=online,offset=126,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=126,lag=1
master_replid:348ec239f98fa46a83fc57b1da9c6347216ec586
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:126
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:126
127.0.0.1:6379>

注：上面这种配置是通过命令配置的，不能长久有效，如果服务重启，配置就会消失，而通过配置文件配置的主从才是永久有效地。

通过配置文件

我们只需要将从机的配置文件进行如下修改：

replicaof  主机ip 端口号
masterauth 主机密码

细节内容：

1.主机可以执行写操作，从机不能写只能读！主机中的所有信息和数据，都会自动被从机保存。

如下：

Client窗口3（主机6379）：

127.0.0.1:6379> set k1 v1 #在主机中写入一个值
OK
127.0.0.1:6379>

Client窗口2（从机6381）：

127.0.0.1:6381> get k1  #在从机中拿到主机写入的值
"v1"
127.0.0.1:6381> set k2 v2 #当在从机中执行写操作会报错
(error) READONLY You can't write against a read only replica.
127.0.0.1:6381>

2.如果主机断开连接，从机依旧是连接到主机的，但是会没有写操作，当主机恢复连接是，从机依旧可以直接获取主机写入的值

3.通过命令配置的主从，如果从机重启，从机就会变为主机，若将其再次设置为从机，它会立马获取主机中的的所有数据信息（进行了一次 全量复制）。

复制原理

Slave（从节点，从机）刚成功连接到Master（主机）后，就会发送一个sync同步命令，Master接到命令后，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台执行完毕之后，master将传送整个数据到slave，完成一次完全同步。

全量复制：用于初次复制或其它无法进行部分复制的情况，将主节点中的所有数据都发送给从节点。当数据量过大的时候，会造成很大的网络开销。
增量复制：master继续将新的所有收集到的修改命令一次传给slave，完成同步，即，主机每进行一次写入操作都会进行一次增量复制，将新增的数据同步给从机。

注意：

只要从机重新连接主机，都会进行一次全量复制。

链式主从模型

点击并拖拽以移动

如上连接模型，同样在主机（6779）中进行写操作，在从机（6380/6381）进行读操作。

如果主机master(6379)断开连接，我们可以在从机6380中执行以下命令让其成为主机：

127.0.0.1:6380> slaveof no one
OK

执行完这个命令，从机6380就会变成主机，如果主机6379又恢复连接，想让6380变成从机，就得通过命令重新配置。

哨兵模式

概念

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

Sentinel能够在后台监控主机是否故障，如果故障了会自动切换从库为主库。

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

点击并拖拽以移动

这里的哨兵有两个作用：

通过发送命令，让redis服务器返回监控其运行状态，包括服务器和从服务器。
当哨兵检测到服务器宕机后，会自动将slave切换成master，然后通过发布订阅模式通知其他服务器，修改配置文件，让它们切换主机。

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

点击并拖拽以移动

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

测试

当前状态：同上采用单机多服务模仿多台redis服务器，一主（6379）二从（6380，6381）

点击并拖拽以移动

1.编写一个简单的哨兵配置文件：

[root@shiyaochang sconfig]# vim  sentinel.conf
[root@shiyaochang sconfig]# ls
redis79.conf  redis80.conf  redis81.conf  redis.conf  sentinel.conf

在配置文件sentinel中输入以下内容，让哨兵监控端口为6379的主节点
sentinel monitor myredis 127.0.0.1  6379  1    
sentinel auth-pass mymaster 123456    #123456为主节点密码

2.启动哨兵:redis-sentinel 配置文件

[root@shiyaochang bin]# redis-sentinel sconfig/sentinel.conf 
12757:X 15 Feb 2021 12:24:25.163 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
12757:X 15 Feb 2021 12:24:25.163 # Redis version=6.0.10, bits=64, commit=00000000, modified=0, pid=12757, just started
12757:X 15 Feb 2021 12:24:25.163 # Configuration loaded
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.0.10 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 12757
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

12757:X 15 Feb 2021 12:24:25.164 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
12757:X 15 Feb 2021 12:24:25.168 # Sentinel ID is ed4d2de017a9b2f364a24c3cd60bb33406aa08b9
12757:X 15 Feb 2021 12:24:25.168 # +monitor master myredis 127.0.0.1 6379 quorum 1
#-------------------------------------检测到哨兵所监控的主机6379的两个从机：--------------------------------
15197:X 15 Feb 2021 12:46:05.886 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:46:05.889 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379

3.断开主机（模仿主节点宕机）

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> shutdown 
not connected> exit
[root@shiyaochang bin]#

4.观察哨兵打印出的日志：

15197:X 15 Feb 2021 12:48:41.462 # +sdown master mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:41.462 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
15197:X 15 Feb 2021 12:48:41.462 # +new-epoch 1
15197:X 15 Feb 2021 12:48:41.462 # +try-failover master mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:41.465 # +vote-for-leader 6e97b389cd0156bda03a54bf8bd316edd36a76c5 1
15197:X 15 Feb 2021 12:48:41.465 # +elected-leader master mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:41.465 # +failover-state-select-slave master mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:41.517 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:41.517 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:41.607 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:41.614 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:41.614 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:41.670 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:42.643 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:42.643 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
15197:X 15 Feb 2021 12:48:42.734 # +failover-end master mymaster 127.0.0.1 6379
#------------------------------如下可见：端口为6381的服务变成主节点------------------------------
15197:X 15 Feb 2021 12:48:42.734 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
15197:X 15 Feb 2021 12:48:42.734 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
#------------------------------端口为6379的服务变成从节点，也就是说当6379重连后，它会变成主节点6380的从节点------------------------------
15197:X 15 Feb 2021 12:48:42.734 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

5.查看6380和6379的replication信息：

127.0.0.1:6380> info replication
# Replication
role:slave  #端口号为6380的redis服务任是从节点
master_host:127.0.0.1
master_port:6381 #主节点变成6381
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:24980
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:fef5c8cb508a9913e2be4657f4b7662a15f2137b
master_replid2:73db7bbdd747fae5a9c4bbf6411abc0cf2e85fb0
master_repl_offset:24980
second_repl_offset:9061
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:24980
127.0.0.1:6380>

127.0.0.1:6381> auth 123456
OK
127.0.0.1:6381> info replication
# Replication
role:master   #6381变成主节点
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=25792,lag=1 #从节点信息
master_replid:fef5c8cb508a9913e2be4657f4b7662a15f2137b
master_replid2:73db7bbdd747fae5a9c4bbf6411abc0cf2e85fb0
master_repl_offset:25925
second_repl_offset:9061
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:25925
127.0.0.1:6381>

6.当原来的主节点（6379）恢复连接后：

当原来的主机重连后，它会变为新选的主机的从机

[root@shiyaochang bin]# redis-server sconfig/redis79.conf #重启服务
[root@shiyaochang bin]# redis-cli -p 6379 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> info replication
# Replication
role:slave #变为6381的从机
master_host:127.0.0.1
master_port:6381
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:1
master_link_down_since_seconds:1613365689
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:f36898ab95dd599885e49f62ceced4b684c09fa6
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:6379>

注意🎈🎈🎈：哨兵切换主从关系是通过修改redis服务配置文件的方式，所以说，其具有长久性，哨兵切换后的主从关系会一直保持，直至哨兵再次切换主从关系，期间即使服务重启，也不会改变。

而且如上测试，当主节点发生改变，哨兵配置文件中所监控的主节点信息也会随之改变：

[root@shiyaochang sconfig]# cat sentinel.conf 
sentinel myid 6e97b389cd0156bda03a54bf8bd316edd36a76c5
sentinel deny-scripts-reconfig yes

# Generated by CONFIG REWRITE
protected-mode no
port 26379
user default on nopass ~* +@all
dir "/usr/local/bin"
sentinel monitor mymaster 127.0.0.1 6381 1 #哨兵叫监控的主节点变成6381
sentinel auth-pass mymaster 123456
sentinel config-epoch mymaster 1
sentinel leader-epoch mymaster 1
sentinel known-replica mymaster 127.0.0.1 6379
sentinel known-replica mymaster 127.0.0.1 6380
sentinel current-epoch 1

哨兵模式优缺点：

优点：

主动可以切换，故障可以转移，系统有更高的可用性
哨兵模式就是主从模式的升级，手动切换主节点变成自动切换

缺点：

Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦。

上述测试只是简单的用哨兵监视了一个主节点，其实哨兵的配置十分复杂，可以监控多个主从节点，以及哨兵之间相互监控。

哨兵配置文案详解：

# Example sentinel.conf
 
# 哨兵sentinel实例运行的端口 默认26379
port 26379
 
# 哨兵sentinel的工作目录
dir /tmp
 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
  sentinel monitor mymaster 127.0.0.1 6379 2
 
# 当在Redis实例中开启了requirepass 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456
 
 
# 指定多少毫秒之后 主节点没有应答哨兵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

给个饭钱？

Post author: Sovzn
Post link: http://sovzn.github.io/2021/02/12/%E4%B8%BB%E4%BB%8E%E5%A4%8D%E5%88%B6/
Copyright Notice: All articles in this blog are licensed under unless otherwise stated.