跳到主要内容

3.1 Redis 主从复制

本节对应 PDF 第 3 章中 3.1 Redis 主从复制 的内容，系统性地介绍：

  • 主从复制架构与应用场景；
  • 如何配置与验证主从复制；
  • 故障时主从复制的恢复过程；
  • 关键配置项与常见问题排查。

3.1.1 Redis 主从复制架构​

Redis 的主从复制与 MySQL 主从模式类似，核心目标有两点：

  • 通过跨主机复制实现 远程备份和冗余；
  • 通过将读请求分散到从节点，提升整体 读性能和可用性。

典型架构中，应用不会直接连单台 Redis，而是：

  1. 先连接到高可用的负载均衡（VIP / LVS / Keepalived 等）；
  2. 由负载均衡将请求转发到后端 Redis 主从集群；
  3. 通过客户端或中间件实现读写分离（写走 master，读走 slave）。

主从复制的基本特性：

  • 一个 master 可以有多个 slave；
  • 一个 slave 只能跟随一个 master；
  • 数据流向是单向的：master → slave；
  • master 默认可读可写；
  • slave 一般配置为只读，用于查询和备份。

在生产环境中，主从复制往往是后续 Sentinel / Cluster 等高可用方案的基础。

3.1.2 主从复制实现与配置​

3.1.2.1 使用命令启用主从复制​

Redis 6 之后推荐使用 REPLICAOF 命令配置从节点，旧版本使用 SLAVEOF：

# 在从节点上执行，指向主节点 IP 和端口
127.0.0.1:6379> REPLICAOF 10.0.0.8 6379

# 旧版命令（逐步被淘汰）
127.0.0.1:6379> SLAVEOF 10.0.0.8 6379

如果主节点启用了密码认证，需要在从节点上配置连接主节点的密码：

127.0.0.1:6379> CONFIG SET masterauth 123456

验证主从角色：

127.0.0.1:6379> INFO replication

在从节点上可以看到：

  • role: slave（或 replica）；
  • master_host、master_port 指向主节点；
  • master_link_status: up 表示复制链路正常；
  • slave_read_only:1 表示只读。

3.1.2.2 取消主从复制​

如果希望取消某个从节点的复制关系，可以在该节点执行：

127.0.0.1:6379> REPLICAOF NO ONE

或旧版本：

127.0.0.1:6379> SLAVEOF NO ONE

取消复制只会断开与 master 的复制关系，不会清空从节点已有数据。此时该节点会变成一个独立的 master。

3.1.2.3 在配置文件中持久化主从关系​

命令行方式适合临时测试，生产环境建议写入 redis.conf：

# 指定主节点
replicaof 10.0.0.8 6379

# 如果主节点有密码
masterauth 123456

# 为了故障时提升为主节点时仍能保护数据，requirepass 一般与 masterauth 保持一致
requirepass 123456

修改后重启 Redis 服务，使主从关系在进程重启后自动生效。

3.1.2.4 验证复制状态与日志​

  1. 在 master 上通过 INFO replication 查看：

    • role: master；
    • connected_slaves 数量；
    • slave0:ip=...,port=...,state=online,... 等从节点状态；
    • repl_backlog_* 表示复制积压缓冲区相关信息。

  2. 在 slave 上通过 INFO replication 查看：

    • role: slave；
    • master_link_status: up/down；
    • master_last_io_seconds_ago：与 master 最近一次通信到现在的秒数；
    • master_sync_in_progress：是否正在进行全量同步。

  3. 在日志中观察复制过程：

    • 初次同步时，slave 日志会出现“连接 master”“请求全量同步”“加载 RDB 到内存”等信息；
    • master 日志会记录“Replica asks for synchronization”“BGSAVE for SYNC”等关键事件。

通过以上命令与日志，可以确认主从复制是否完成、链路是否稳定。

3.1.3 主从复制与持久化的安全性​

PDF 中专门强调了一个非常典型、也非常危险的场景：

  1. 主节点关闭了 RDB/AOF 持久化；
  2. 主节点发生故障后，由进程守护程序自动快速重启；
  3. 由于没有持久化文件，重启后的主节点是“空数据”；
  4. 从节点认为这是一次正常同步，从新的主节点同步，结果把自己原有的数据也清空了。

如果再叠加 Sentinel 的自动故障转移机制，主节点重启速度足够快时，Sentinel 甚至可能来不及感知主节点曾经“消失”，依然认为这是同一个 master，从而触发上述“全量清空”链路。

因此：

  • 强烈建议：在启用主从复制的场景下，不要关闭主节点的持久化功能；
  • 如果确实要关闭，也应禁止主节点服务被自动拉起，避免在无人值守情况下发生集体数据丢失；
  • 无论是否使用 Sentinel，高可用方案都应该优先保证数据安全，而不是一味追求自动恢复速度。

3.1.4 主从复制故障恢复​

3.1.4.1 从节点故障与恢复​

当某个 slave 宕机时：

  • 业务侧可以暂时将读请求切换到其他 slave；
  • 修复故障节点后，将其重新配置为原 master 的从节点；
  • 启动后会再次经历一次全量或部分同步，日志中可以看到重新握手与同步的过程。

如果复制 ID 已变化或丢失缓存信息，Redis 会选择执行一次全量同步（重新生成 RDB 并传给 slave）。

3.1.4.2 主节点故障时的手工切换​

在未引入 Sentinel 之前，主节点故障需要手动切换：

  1. 选择一个数据最新的 slave；
  2. 在该从节点执行 REPLICAOF NO ONE，将其提升为新的 master；
  3. 将其他从节点指向新的 master；
  4. 更新负载均衡或客户端配置，使写请求指向新的 master。

这套流程可以被 Sentinel 自动化，但理解其手工步骤有助于排查复杂故障。

3.1.5 关键配置项与复制延迟控制​

3.1.5.1 min-replicas-to-write / min-replicas-max-lag​

这两个参数用于控制在复制健康度较差时是否允许 master 继续处理写请求：

min-replicas-to-write 1
min-replicas-max-lag 20

含义可以理解为：

  • 至少需要有 min-replicas-to-write 个从节点；
  • 每个从节点与主节点的复制延迟不得超过 min-replicas-max-lag 秒；
  • 一旦不满足条件，master 将拒绝写请求，以降低在严重网络抖动时的数据丢失风险。

在金融、订单等对数据安全高度敏感的场景中，合理设置这两个参数非常重要。

3.1.5.2 内存与版本配置一致性​

为减少主从不一致问题，建议：

  • master 与 slave 使用 相同大版本 的 Redis；
  • maxmemory、淘汰策略等内存相关配置尽量保持一致；
  • 避免在从节点上设置比主节点更严格的内存限制，否则可能因内存淘汰导致从节点缺少部分键值。

3.1.5.3 安全相关配置的一致性​

常见坑包括：

  • 在 master 上通过 rename-command 重命名了敏感命令（如 FLUSHALL、CONFIG 等），但在 slave 上没有同步配置，导致复制或运维行为异常；
  • 保护模式（protected-mode）、bind、requirepass 等安全配置在主从之间不一致，出现“本机能连、远程连不上”的情况。

建议将主从节点视作一个整体来管理配置，通过统一的模板或配置管理系统下发。

3.1.6 常见问题排查清单​

结合 PDF 案例和实际运维经验，可以从以下角度排查主从复制问题：

  1. 认证相关：

    • masterauth 是否正确；
    • 日志中是否有认证失败提示；
    • 是否开启了 ACL 并影响了复制连接。

  2. 网络连通性：

    • 防火墙 / 安全组是否放通 6379 端口；
    • master_link_status 是否长期处于 down；
    • master_last_io_seconds_ago 是否持续为 -1 或极大值。

  3. 磁盘与持久化：

    • 主节点执行 BGSAVE 是否失败；
    • 磁盘空间是否充足；
    • AOF/RDB 文件是否可写、权限是否正确。

  4. 配置不一致：

    • maxmemory / 淘汰策略 / rename-command 是否主从一致；
    • 是否在 slave 上误开启了写入（slave-read-only no）。

  5. 版本与 Bug：

    • 确认主从版本是否一致，且为社区推荐的稳定版本；
    • 遇到疑难问题时，注意查询对应版本的变更记录与已知缺陷。

通过合理设计架构、正确配置复制参数、并结合日志与监控进行持续观察，可以使 Redis 主从复制在生产环境中稳定可靠地运行。