Redis高可用系列

• 《Redis高可用实战之Replication》
• 《Redis高可用实战之Sentinel》
• 《Redis高可用实战之Cluster》

前言

上一篇《Redis高可用实战之Replication》介绍了 Redis 的主从复制，但是当节点故障时无法进行故障转移，所以我们需要使用 Redis Sentinel 来进一步提高 Redis 的可用性。

Redis Sentinel 作为一个分布式系统，可以监测主实例和副本的可用性，使用 API 发出通知。更重要的是它可以完成自动故障转移，并将新的主实例地址告诉客户端。

安装 Redis 时已经包含了 Redis Sentinel 的执行文件，可以通过redis-sentinel命令来运行 Sentinel。

我们在上一篇主从复制演示环境的基础上进行 Sentinel 的测试。

修改配置

在 Redis 目录下，编辑sentinel.conf文件，增加所要监测的主节点名称、地址和端口，其格式为：

sentinel monitor    
1

quorum 参数是当 master 故障时，需要多少个 sentinel 实例认定该 master 不可达，以便真正将 master 标记为失败，并在可能的情况下最终启动故障转移过程。

我们演示的是三个节点的情况，至少需要2个 sentinel 认定 master 的故障状态，修改后的配置：

sentinel monitor mymaster 192.168.1.201 6379 2
1

启动Sentinel

redis-sentinel sentinel.conf
1

或者使用redis-server命令以sentinel模式运行：

redis-server sentinel.conf --sentinel
1

Sentinel 实例间使用26379端口进行状态同步。

可以使用客户端程序redis-cli连接26379端口以执行SENTINEL相关命令。

[root@node1 ~]# redis-cli -p 26379
127.0.0.1:26379> SENTINEL GET-MASTER-ADDR-BY-NAME mymaster
1) "192.168.1.201"
2) "6379"
1
2
3
4

测试验证

当关闭主节点 Redis 实例后，此时副本节点日志提示了不能进行复制的错误：

6926:S 10 Aug 2022 17:49:32.550 * MASTER <-> REPLICA sync started
6926:S 10 Aug 2022 17:49:32.551 # Error condition on socket for SYNC: Connection refused
1
2

10秒钟后，查看 Sentinel 的日志，观察自动故障转移的过程。

14789:X 10 Aug 2022 17:49:39.702 # +sdown master mymaster 192.168.1.201 6379
14789:X 10 Aug 2022 17:49:39.755 * Sentinel new configuration saved on disk
14789:X 10 Aug 2022 17:49:39.755 # +new-epoch 1
14789:X 10 Aug 2022 17:49:39.758 * Sentinel new configuration saved on disk
14789:X 10 Aug 2022 17:49:39.758 # +vote-for-leader c0ead4f87c8b2d6d73bed40e390997d26798efc2 1
14789:X 10 Aug 2022 17:49:39.805 # +odown master mymaster 192.168.1.201 6379 #quorum 3/2
14789:X 10 Aug 2022 17:49:39.805 # Next failover delay: I will not start a failover before Wed Aug 10 17:55:40 2022
14789:X 10 Aug 2022 17:49:40.194 # +config-update-from sentinel c0ead4f87c8b2d6d73bed40e390997d26798efc2 192.168.1.203 26379 @ mymaster 192.168.1.201 6379
14789:X 10 Aug 2022 17:49:40.194 # +switch-master mymaster 192.168.1.201 6379 192.168.1.202 6379
14789:X 10 Aug 2022 17:49:40.194 * +slave slave 192.168.1.203:6379 192.168.1.203 6379 @ mymaster 192.168.1.202 6379
14789:X 10 Aug 2022 17:49:40.194 * +slave slave 192.168.1.201:6379 192.168.1.201 6379 @ mymaster 192.168.1.202 6379
14789:X 10 Aug 2022 17:49:40.257 * Sentinel new configuration saved on disk
14789:X 10 Aug 2022 17:50:10.214 # +sdown slave 192.168.1.201:6379 192.168.1.201 6379 @ mymaster 192.168.1.202 6379
1
2
3
4
5
6
7
8
9
10
11
12
13
14

首先认定192.168.1.201节点处于关闭状态，然后开始选举新的master，超过quorum数量的实例认定原master处于客观关闭状态，切换新的master并开始执行故障转移。

此时可以看到192.168.1.202已经成为了新的 master：

[root@node1 ~]# redis-cli -p 26379
127.0.0.1:26379> SENTINEL GET-MASTER-ADDR-BY-NAME mymaster
1) "192.168.1.202"
2) "6379"
1
2
3
4

当重启被关闭的 Redis 实例后，它将作为新的 master 的副本。

[root@node1 ~]# redis-cli -h 192.168.1.201 -p 6379
192.168.1.201:6379> info replication
# Replication
role:slave
master_host:192.168.1.202
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_read_repl_offset:277408
slave_repl_offset:277408
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:b5f3594f269a3076efd652546b12ac09189e87df
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:277408
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:243900
repl_backlog_histlen:33509
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

参考资料

官方文档