Redis 主从复制和哨兵模式

news2024/10/6 10:32:01

一、概念

        主从复制，是指将一台 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

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/954340.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

利用条件竞争突破优惠券仅能使用一次逻辑限制

利用条件竞争突破优惠券仅能使用一次逻辑限制

Portswigger练兵场之条件竞争 目录 Portswigger练兵场之条件竞争&#x1f984;条件竞争-突破一次逻辑限制&#x1f680;实验前置必要知识点&#x1f3c6;实验要求⚡️渗透开始1. 站点分析2. 登录3.日志探查4.功能点探究5.完成实验 修复方案 &#x1f984;条件竞争-突破一次逻辑…
阅读更多...
java八股文面试[多线程]——线程池拒绝策略

java八股文面试[多线程]——线程池拒绝策略

四种线程池拒绝策略&#xff08;handler&#xff09; 当线程池的线程数达到最大线程数时&#xff0c;需要执行拒绝策略。拒绝策略需要实现 RejectedExecutionHandler 接口&#xff0c;并实现 rejectedExecution(Runnable r, ThreadPoolExecutor executor) 方法。不过…
阅读更多...
前端基础2——CSS样式

前端基础2——CSS样式

文章目录 一、使用方式1.1 内联方式1.2 内部方式1.3 外部导入方式&#xff08;推荐&#xff09; 二、选择器类型2.1 元素选择器2.2 ID选择器2.3 类选择器2.4 派生选择器 三、常用属性3.1 内边距和外边距3.2 文本3.3 边框3.4 背景3.5 定位3.6 浮动3.7 字体3.8 其他属性 四、案例…
阅读更多...
信息技术02--初/高中--分类选择题(377道题与解析)

信息技术02--初/高中--分类选择题(377道题与解析)

文章目录 第一章 办公软件 1-96第二章 信息技术基础 1-41第三章 计算机系统基础 1-28第四章 多媒体技术 1-115第五章 计算机网络技术 1-50第六章 信息安全 1-3第七章 算法与程序简介 1-13第八章 数据结构 1-2第九章 数据库技术 1-20第十章 练习 1-9 第一章 办公软件 1-96 1、某…
阅读更多...
Cygwin是什么？是Windows还是Linux？

Cygwin是什么？是Windows还是Linux？

原文作者&#xff1a;gentle_zhou 原文链接&#xff1a;https://bbs.huaweicloud.com/blogs/408674 最近在和客户交流的时候&#xff0c;一直以为客户的研发环境就是windows 7&#xff0c;直到和对面的研发团队交流的时候&#xff0c;得到的反馈是在windows 7系统上安装了Cygw…
阅读更多...
C语言深入理解指针（非常详细）（一）

C语言深入理解指针（非常详细）（一）

目录 内存和地址内存编址的理解 指针变量和地址取地址操作符&#xff08;&&#xff09;指针变量和解引用操作符&#xff08;*&#xff09;指针变量如何拆解指针类型解引用操作符 指针变量的大小 指针变量类型的意义指针的解引用指针-整数 const修饰指针const修饰变量const修…
阅读更多...
智慧园区封闭化管理之人车定位及轨迹追踪

智慧园区封闭化管理之人车定位及轨迹追踪

园区封闭化管理在提高园区安全性、管理效率方面发挥着重要作用&#xff0c;人车定位及轨迹追踪是推动园区智慧封闭化管理的关键技术。本文将探讨人车定位及轨迹追踪技术在智慧园区封闭化管理中的应用&#xff0c;带您了解数字化时代园区管理的创新之路。 一、人车定位技术的突破…
阅读更多...
Echarts遇到Vue3时遇到的问题

Echarts遇到Vue3时遇到的问题

将vue2的Echarts代码迁移到了vue3项目上&#xff0c;引发的问题 问题描述&#xff1a; 1. 点击图例legend时刻度轴偏移&#xff0c;图像不展示&#xff0c;以及报错 初始chart正常.图 点击图例后的chart和报错.图 2. 调用resize()不生效且报错 初始正常.图 修改屏幕尺寸调用r…
阅读更多...
[ Linux Audio 篇 ] Linux Audio 子系统资料集锦

[ Linux Audio 篇 ] Linux Audio 子系统资料集锦

Linux Audio 子系统资料 背景OSS VS ALSAALSA 驱动ALSA libALSA Plugin音频延迟音频调试音频书籍 背景 最近需要准备Linux Audio 相关的PPT&#xff0c;于是将以往的知识点和遇到的问题进行整理和梳理&#xff0c;以便向大家讲解。同时&#xff0c;还整理了在这个过程中发现的…
阅读更多...
小技巧，将你的Python代码运行情况用动画实时呈现

小技巧，将你的Python代码运行情况用动画实时呈现

咱们初学者练习编程时&#xff0c;常常难以理解简单循环&#xff0c;数据结构&#xff0c;迭代的操作原理。 现在不怕了&#xff0c;我们可以借助一个在线工具逐步执行代码&#xff0c;并直观查看其运行过程。 它是由 Philip Guo 开发的一个免费教育工具&#xff0c;帮助学生攻…
阅读更多...
这5个理由告诉你为什么要采用微前端架构

这5个理由告诉你为什么要采用微前端架构

微前端是一种前端开发的架构方法&#xff0c;已经变得越来越流行&#xff0c;这也预示着它很可能代表 Web 开发的未来。所以学习这种架构带来的好处对你的应用程序和开发团队是不言而喻的。 本文将分享我和我的团队使用这种方法两年来的经验所得&#xff0c;以及帮助你分析在你…
阅读更多...
仿弹壳特工队，绝地反击活动使用电池翻格子小游戏(JAVA小游戏)

仿弹壳特工队，绝地反击活动使用电池翻格子小游戏(JAVA小游戏)

近来太无聊&#xff0c;玩了一款割草游戏&#xff0c;里面有个活动感觉挺好玩的&#xff0c;像扫雷一样&#xff0c;寻找线索(灯泡)&#xff0c;在这里使用JAVA语言也简单实现下游戏。 先上效果图&#xff0c;鼠标点击对应的块&#xff0c;可以展开相连的方块&#xff0c;点击…
阅读更多...
nvm集合node版本，解决新版本jeecgboot3.5.3前端启动失败问题

nvm集合node版本，解决新版本jeecgboot3.5.3前端启动失败问题

jeecgboot前端3.5.3页面如下 使用之前的pnpm启动会报错&#xff0c;pnpm是node进行安装的&#xff0c;查询后发现&#xff0c;vue3版本的页面至少需要node16版本&#xff0c;我之前的版本只有15.5&#xff0c;适用于vue2 那么我将先前的node15.5版本删除&#xff0c;然后安装…
阅读更多...
【知识分享】C语言应用-易错篇

【知识分享】C语言应用-易错篇

一、C语言简介 C语言结构简洁&#xff0c;具有高效性和可移植性&#xff0c;因此被广泛应用。但究其历史的标准定义&#xff0c;C语言为了兼容性在使用便利性作出很大牺牲。在《C陷阱与缺陷》一书中&#xff0c;整理出大部分应用过程中容易出错的点&#xff0c;本文为《C陷阱与…
阅读更多...
ffmpeg把RTSP流分段录制成MP4，如果能把ffmpeg.exe改成ffmpeg.dll用，那音视频开发的难度直接就降一个维度啊

ffmpeg把RTSP流分段录制成MP4，如果能把ffmpeg.exe改成ffmpeg.dll用，那音视频开发的难度直接就降一个维度啊

比如&#xff0c;原来我们要用ffmpeg录一段RTSP视频流转成MP4&#xff0c;我们有两种方案&#xff1a; 方案一&#xff1a;可以使用以下命令将rtsp流分段存储为mp4文件 ffmpeg -i rtsp://example.com/stream -vcodec copy -acodec aac -f segment -segment_time 3600 -reset_t…
阅读更多...
ubuntu20.04+ROS noetic在线运行单USB双目ORB_SLAM

ubuntu20.04+ROS noetic在线运行单USB双目ORB_SLAM

双目摄像头主要有以下几种&#xff0c;各有优缺点。 1.单USB插口&#xff0c;左右图像单独输出2.双USB插口&#xff0c;左右图像单独输出&#xff08;可能存在同步性问题&#xff09;3.双USB插口&#xff0c;左右图像合成输出4.单USB插口&#xff0c;左右图像合成输出 官方版…
阅读更多...
【C++】线程安全问题

【C++】线程安全问题

原子类型非线程安全 #include <iostream> #include <thread>int main() {int num 0;int count 100000;std::thread thread1([&](){for(int i 0; i < count; i){num;}});std::thread thread2([&](){for(int i 0; i < count; i){num;}});std::thr…
阅读更多...
jsp+servlet零食商城java网上购物超市Mysql源代码

jsp+servlet零食商城java网上购物超市Mysql源代码

本项目为前几天收费帮学妹做的一个项目&#xff0c;Java EE JSP项目&#xff0c;在工作环境中基本使用不到&#xff0c;但是很多学校把这个当作编程入门的项目来做&#xff0c;故分享出本项目供初学者参考。 一、项目介绍 项目名:网上零食商城 技术栈 jspservlet 系统有3权限…
阅读更多...
动静分红，循环购模式：微三云门门

动静分红，循环购模式：微三云门门

动静分红&#xff0c;循环购模式&#xff1a;微三云门门 商业模式概述&#xff1a; 动静分红&#xff0c;循环购模式是一种创新商业模式&#xff0c;旨在解决平台用户复购率和C端裂变的难题。该模式以能量值和贡献值为核心资产&#xff0c;结合动态和静态奖金池&#xff0c;为…
阅读更多...
产品展示视频拍摄制作流程

产品展示视频拍摄制作流程

通过精心策划和制作的产品展示视频&#xff0c;展示产品的独特魅力和卓越功能。激发受众对产品的兴趣和购买欲望。为了确保产品展示视频的制作质量和效果&#xff0c;需要团队一起探讨具体的拍摄制作流程。深圳产品活动视频制作公司老友记小编为您分析产品展示视频的拍摄制作过…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023