Redis 主从复制和哨兵监控，实现Redis高可用配置

最新推荐文章于 2024-05-30 15:07:56 发布

QIFU

最新推荐文章于 2024-05-30 15:07:56 发布

阅读量582

点赞数

分类专栏： # Redis 文章标签： redis 数据库缓存分布式

本文链接：https://blog.csdn.net/qifu123/article/details/134078535

版权

Redis 专栏收录该内容

12 篇文章 2 订阅

订阅专栏

文章目录

如果您对Redis的了解不够深入请关注本栏目，本栏目包括Redis安装，Redis配置文件说明，Redis命令和数据类型说明，Redis持久化配置。

一、概述

Redis 主从复制是 Redis 提供的一种数据复制机制，用于实现数据冗余和高可用性。在主从复制中，一个 Redis 节点（主节点）负责接收写操作并将数据复制到一个或多个从节点。从节点复制主节点的数据，并且在主节点发生故障时可以接管成为新的主节点，以保持服务的可用性。
通过主从复制，Redis 构建了一个具有冗余数据和自动故障切换能力的分布式系统，提高了系统的可用性和容错能力。此外，Redis 主从复制还允许根据业务需求动态添加或移除从节点，以适应负载变化和扩展需求。满足AKF软件架构概念，即可用性（Availability）、可扩展性（Scalability）和灵活性（Flexibility）。
Redis 主从复制在一定程度上牺牲了一致性。在主从复制的架构中，当主节点发生故障时，从节点会接管成为新的主节点，但在切换过程中可能会存在数据的不一致性。这是因为主从复制采用异步复制的方式，导致从节点的数据可能会有一段时间的延迟。这是一个分布式系统设计CAP理论，即一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）。CAP 理论指出在一个分布式系统中，无法同时满足这三个属性，最多只能同时满足其中两个。
数据一致性有两种方式，即强一致性（所有节点阻塞直到数据全部一致）和最终一致性（异步方式）。因为强一致破坏了可用性，最终一致性会导致数据不一致。所以实使用时需结合实际情况选择。

二、主从复制模拟说明

在一台主机上开启3个Redis服务来模拟Redis主从复制。我这里配置端口6381为主，6382和6383为从。示意图如下：

在这里插入图片描述

三、准备配置文件

新建3个配置文件，分别为 redis_6381.conf、redis_6382.conf、redis_6383.conf（您也可以把原redis.conf直接复制三份，然后修改端口、数据目录和进程ID文件即可），有关配置项的详细解释请看Redis配置文件说明。
redis_6381.conf

# 导入默认 redis 配置文件
include redis.conf
# 配置端口
port 6381
# 配置数据目录
dir /var/lib/redis/6381
# 配置进程ID文件
pidfile /var/run/redis_6381.pid

# 以下参数可选
# supervised no
# daemonize no
# logfile ""
# appendonly no

redis_6382.conf

# 导入默认 redis 配置文件
include redis.conf
# 配置端口
port 6382
# 配置数据目录
dir /var/lib/redis/6382
# 配置进程ID文件
pidfile /var/run/redis_6382.pid

# 以下参数可选
# supervised no
# daemonize no
# logfile ""
# appendonly no

# replicaof  127.0.0.1 6381

redis_6383.conf

# 导入默认 redis 配置文件
include redis.conf
# 配置端口
port 6383
# 配置数据目录
dir /var/lib/redis/6383
# 配置进程ID文件
pidfile /var/run/redis_6383.pid

# 以下参数可选
# supervised no
# daemonize no
# logfile ""
# appendonly no

# replicaof  127.0.0.1 6381

注意，配置完成后要检查以上配置目录是否存在，如果不存请手动创建，如下：
```
mkdir -p /var/lib/redis/6381 /var/lib/redis/6382 /var/lib/redis/6383
```

四、启动Redis实例

分别启3个Redis服务实例。

# 主节点，端口6381
redis-server redis_6381.conf
# 从节点1，端口6382
redis-server redis_6382.conf
# 从节点2，端口6383
redis-server redis_6383.conf

五、主从复制配置

5.1 命令方式启用和取消主从复制

启用主从复制
- 使用redis-cli分别连接6382、6383端口的Redis服务，然后使用 REPLICAOF 命令将自己作为从节点，加入到主节点6381中（旧版Redis中使用SLAVEOF命令）即完成主从复制的Redis配置。如下

REPLICAOF 127.0.0.1 6381

[root@yiqifu-redis ~]# redis-cli -p 6382
127.0.0.1:6381> REPLICAOF 127.0.0.1 6381
OK

[root@yiqifu-redis ~]# redis-cli -p 6383
127.0.0.1:6381> REPLICAOF 127.0.0.1 6381
OK

取消主从复制
- 取消作为从节点，相当于把自己升为主节点

REPLICAOF no one

[root@yiqifu-redis ~]# redis-cli -p 6382
127.0.0.1:6381> REPLICAOF no one
OK

5.2 配置文件方式启用和取消主从复制

启用只需分别在redis_6382.conf、redis_6383.conf 配置文件中添加以下配置，然后重起Redis服务即可。
取消则把以下配置删除即可。

# replicaof <masterip> <masterport>
replicaof  127.0.0.1 6381

5.3 测试主从复制

完成后你可以在6381上添加数据，然后从6382和6383上读取数据

[root@yiqifu-redis conf]# redis-cli -p 6381
127.0.0.1:6381> set aaa 111
OK
127.0.0.1:6381>
[root@yiqifu-redis conf]# redis-cli -p 6382
127.0.0.1:6382> keys *
1) “aaa”
127.0.0.1:6382>
[root@yiqifu-redis conf]# redis-cli -p 6383
127.0.0.1:6383> keys *
1) “aaa”
127.0.0.1:6383>

5.4 有其主从复制的其他参数配置

根据业务情况选择

### 对于主机
# 在主从复制模式中，主机向从机同步数据时，是否直接通过网络发送，而不是先在磁盘建立RDB然后再同步。
# 也就是yes就是直接从网络发，no就是先存磁盘，然后再发
repl-diskless-sync no
# 在主从复制模式中，复制的缓存区大小。
# 太小可能会因为从机无法追赶上主服务的操作而导致复制延迟。太大又会占用更多空间
# repl-backlog-size 1mb

### 对于从机
# 在主从复制模式中，在从机同步主机数据过程中，是否暴露原数据。
# 也就是从机在同步主机数据的过程中，是否让应用程序可以访问从机的未同步前的数据
replica-serve-stale-data yes
# 在主从复制模式中，从机是否为只读模式
replica-read-only yes

### 对于 Sentinel
# 设置在执行写操作之前，Sentinel 要求的最少副本数量。
# 例如，如果你将 min-replicas-to-write 设置为3，那么在执行写操作之前，至少需要有3个从服务器（副本）是可用的，以确保数据的高可用性和一致性。
# 如果可用的从服务器数量低于配置的值，写操作将被拒绝，以确保数据的完整性。
# min-replicas-to-write 3
# 设置从服务器的最大复制延迟。
# 例如，如果你将 min-replicas-max-lag 设置为10，那么当从服务器的复制延迟超过10秒时，Sentinel不再将其视为可用的副本。
# 这是为了确保只有具有较低延迟的从服务器被认为是可用的，以防止可能导致数据不一致的情况。
# min-replicas-max-lag 10

六、Sentinel 配置

6.1 Sentinel 的作用

在前面的配置中当主节点挂掉以后，就没有主了，想要恢复只能手动。而Sentinel的的作用的就是监控这些Redis服务，当主节点挂掉以后会自动选一个可用的从节点升级为主机，保证服务的可用性。
具体来说，Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance），实现在Redis的高可用，该系统执行以下三个任务：
- 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
- 提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
- 自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

6.2 Sentinel 监控说明

同样，我们也一台主机上开启3个Sentinel 服务来监控 Redis主从复制服务实例。我这里配置端口26381、26382和26383。

6.3 Sentinel 配置文件

新建3个配置文件，分别为 sentinel_26381.conf、sentinel_26382.conf、sentinel_26383.conf。分别用来监控Redis主从实例6381、6382和6383。
sentinel_26381.conf

port 26381
sentinel monitor mymaster 127.0.0.1 6381 2

sentinel_26382.conf

port 26382
sentinel monitor mymaster 127.0.0.1 6381 2

sentinel_26383.conf

port 26383
sentinel monitor mymaster 127.0.0.1 6381 2

6.4 开启 Sentinel

redis-sentinel sentinel_26381.conf
redis-sentinel sentinel_26382.conf
redis-sentinel sentinel_26383.conf

也可通过这种方式启动：redis-server sentinel_26381.conf --sentinel

6.5 测试

成功开启后如果Redis服务6381停止，Sentinel 会在 6382 和 6383 中选一台升级为主。当再次启动 6381 时，Sentinel 会把他作为从加入当前主中。以下是我测试时的日志：

Redis 6381 用户停止

6277:M 27 Oct 2023 15:53:23.922 # User requested shutdown…
6277:M 27 Oct 2023 15:53:23.922 * Saving the final RDB snapshot before exiting.
6277:M 27 Oct 2023 15:53:23.951 * DB saved on disk
6277:M 27 Oct 2023 15:53:23.951 * Removing the pid file.
6277:M 27 Oct 2023 15:53:23.951 # Redis is now ready to exit, bye bye…

Redis 6382 被 Sentinel 选为主

6126:M 27 Oct 2023 15:53:54.391 * Discarding previously cached master state.
6126:M 27 Oct 2023 15:53:54.391 # Setting secondary replication ID to 00cd50f9815b69bcda4fc80abc782afc0a4785da, valid up to offset: 17475. New replication ID is f1aa0d5cb34adbf6d20f1bc8a3824e1b77304fa6
6126:M 27 Oct 2023 15:53:54.391 * MASTER MODE enabled (user request from ‘id=10 addr=127.0.0.1:58452 fd=8 name=sentinel-18226c99-cmd age=590 idle=0 flags=x db=0 sub=0 psub=0 multi=4 qbuf=188 qbuf-free=32580 obl=45 oll=0 omem=0 events=r cmd=exec user=default’)
6126:M 27 Oct 2023 15:53:54.392 # CONFIG REWRITE executed with success.
6126:M 27 Oct 2023 15:53:54.771 * Replica 127.0.0.1:6383 asks for synchronization
6126:M 27 Oct 2023 15:53:54.772 * Partial resynchronization request from 127.0.0.1:6383 accepted. Sending 156 bytes of backlog starting from offset 17475.

Redis 6383 作为从跟随 6382

6153:S 27 Oct 2023 15:53:54.708 * REPLICAOF 127.0.0.1:6382 enabled (user request from ‘id=8 addr=127.0.0.1:57678 fd=10 name=sentinel-18226c99-cmd age=590 idle=0 flags=x db=0 sub=0 psub=0 multi=4 qbuf=329 qbuf-free=32439 obl=45 oll=0 omem=0 events=r cmd=exec user=default’)
6153:S 27 Oct 2023 15:53:54.709 # CONFIG REWRITE executed with success.
6153:S 27 Oct 2023 15:53:54.769 * Connecting to MASTER 127.0.0.1:6382
6153:S 27 Oct 2023 15:53:54.769 * MASTER <-> REPLICA sync started
6153:S 27 Oct 2023 15:53:54.769 * Non blocking connect for SYNC fired the event.
6153:S 27 Oct 2023 15:53:54.771 * Master replied to PING, replication can continue…
6153:S 27 Oct 2023 15:53:54.771 * Trying a partial resynchronization (request 00cd50f9815b69bcda4fc80abc782afc0a4785da:17475).
6153:S 27 Oct 2023 15:53:54.773 * Successful partial resynchronization with master.
6153:S 27 Oct 2023 15:53:54.773 # Master replication ID changed to f1aa0d5cb34adbf6d20f1bc8a3824e1b77304fa6
6153:S 27 Oct 2023 15:53:54.773 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.

Sentinel 26381 被 Sentinel 26382 和 26383 选举为 leader，然后协调 Redis 6382 为 Master 和 Redis 6383 为 Slave 的过程日志

6214:X 27 Oct 2023 15:53:54.213 # +elected-leader master mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.213 # +failover-state-select-slave master mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.307 # +selected-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.307 * +failover-state-send-slaveof-noone slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.390 * +failover-state-wait-promotion slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.628 # +promoted-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.628 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.708 * +slave-reconf-sent slave 127.0.0.1:6383 127.0.0.1 6383 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:55.265 # -odown master mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:55.612 * +slave-reconf-inprog slave 127.0.0.1:6383 127.0.0.1 6383 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:55.612 * +slave-reconf-done slave 127.0.0.1:6383 127.0.0.1 6383 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:55.664 # +failover-end master mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:55.664 # +switch-master mymaster 127.0.0.1 6381 127.0.0.1 6382
6214:X 27 Oct 2023 15:53:55.665 * +slave slave 127.0.0.1:6383 127.0.0.1 6383 @ mymaster 127.0.0.1 6382
6214:X 27 Oct 2023 15:53:55.665 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6382
6214:X 27 Oct 2023 15:54:25.741 # +sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6382

QIFU

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
2
评论
Redis 主从复制和哨兵监控，实现Redis高可用配置

Redis 主从复制是 Redis 提供的一种数据复制机制，用于实现数据冗余和高可用性。在主从复制中，一个 Redis 节点（主节点）负责接收写操作并将数据复制到一个或多个从节点。从节点复制主节点的数据，并且在主节点发生故障时可以接管成为新的主节点，以保持服务的可用性。通过主从复制，Redis 构建了一个具有冗余数据和自动故障切换能力的分布式系统，提高了系统的可用性和容错能力。此外，Redis 主从复制还允许根据业务需求动态添加或移除从节点，以适应负载变化和扩展需求。
复制链接

扫一扫