1. 环境与准备
1.1 集群拓扑与角色分布
在排查过程的第一步，明确集群拓扑、主从结构及端口暴露情况。通过 INFO replication 可以快速看到 master 与所有 slave 的状态、以及从节点数量等信息。若拓扑中存在多层级的从节点，应对每一级别的复制状态进行确认。
此外，确认网络连通性与防火墙策略是否阻塞 Redis 之间的心跳通道。例如 master <-> slave 的 TCP 连接 是否长期处于 ESTABLISHED，以及是否有网络抖动导致的断连。
redis-cli -h 192.168.1.10 -p 6379 INFO replication
redis-cli -h 192.168.1.11 -p 6379 INFO replication
本指南围绕 Redis 主从复制故障排查指南，提供面向后端开发与运维的 实战排错步骤，帮助定位与解决复制问题。
1.2 版本与配置对齐
确认 Redis 版本与编译参数是否在受支持的范围内，版本不一致会带来复制相关的兼容性问题，例如 RDB 与 AOF 的冲突，以及 复制缓冲区大小与 repl-backlog 的配置差异。
对 master 和 slave 的配置进行对比，确保 slaveof 指向正确的 master，masterauth、replica-read-only 等策略一致。
grep -E '^[#;]|^port|^bind|^cluster-enabled' /etc/redis/redis.conf
2. 基本故障现象与日志定位
2.1 常见现象描述
常见现象包括：主节点延迟飙升、从节点 lag 增大、复制阻塞、master_link_status: up 但 master_sync_in_progress 为 true。定位要点是观察 replication 信息中的 master_link_status、slave0 的状态，以及 repl_backlog_time。
监控工具需覆盖 INFO REPLICATION、LOG、以及系统层面的网络状态。通过这些信号可以快速判断是网络、磁盘 I/O 还是 CPU 资源导致的复制瓶颈。
redis-cli -h 192.168.1.12 -p 6379 INFO replication
tail -n +1 /var/log/redis/redis-server.log | grep -i 'warning\\|error' | tail -n 50
2.2 日志分析要点
日志中的 error、warning、以及 repl 前缀日志是排错的入口。聚焦字段包括 master_link_status、repl_backlog_size、以及 repl_back_log 的最近条目。
在日志中如果出现 Master is not up or terminated、Slave myid not found、或 duplicate key 等信息，需结合配置和网络状态进行排错。
3. 复制链路诊断与恢复
3.1 检查复制链路连通性
确定 master、slave 间的网络连通性没有被防火墙拦截，且 端口 6379 可达。对于跨数据中心的部署，需额外关注 延迟 与 抖动 对复制时序的影响。
结合 time 与 REPL 相关时间戳，判断是否存在 脑裂 状态，若发现 master_last_io_seconds_ago 持续偏大，说明 Master 与 Slave 之间的心跳可能中断。
redis-cli -h 10.0.0.1 -p 6379 INFO replication
redis-cli -h 10.0.0.2 -p 6379 INFO replication
3.2 处理复制滞后与阻塞
对于从节点滞后较大，应优先查看 repl_backlog_size、repl_back_log，以及系统 I/O 的瓶颈。必要时可通过调整 repl-backlog-size 与 repl-backlog 相关参数来缓解。此处需要具备对 AOF 或 RDB 的影响评估能力。
在阻塞场景下，应分析 慢 SQL、磁盘 I/O 与 网络抖动 的叠加效应，确保主从端都具备足够的 写入带宽与队列容量。如有必要，立即进行数据同步的分阶段恢复。
redis-cli -p 6379 CONFIG SET repl-backlog-size 1048576
python - << 'PY'
import redis
r = redis.Redis(host='redis-master', port=6379)
print(r.info('replication').get('repl_backlog_size'))
PY
4. 故障场景下的恢复策略
4.1 从节点重新指向正确的 Master
在主从复制关系出现错位时，从节点需要重新指向正确的 Master，避免 延时或数据不一致。通过 SLAVEOF 或 REPLICAOF 指令对从节点进行重新指向，并确保 masterauth 与认证信息一致。
恢复策略应包含对比 数据一致性校验，确保从节点具备最新的镜像数据，并且不会在下次重启后触发新的同步。
redis-cli -h slave1 -p 6379 REPLICAOF master1 6379
4.2 自动容错与故障转移要点
在高可用架构中，哑节点/哨兵 或 集群模式 提供自动故障转移能力。当主节点宕机时，监控系统需要快速定位到新的主节点，并将从节点切换。注意切换时对 数据回放 与 写入顺序 的影响。
为避免重复写入，应限定 写入幂等性 和 避免冲突的写入顺序，并在切换完成后进行 全量一致性检查。
redis-cli -p 26379 SENTINEL failover mymaster
5. 常见场景与排错清单
5.1 场景回顾：网络抖动引发的复制中断
在网络波动较大时，master 和 slave 的心跳丢失，复制链路会出现短时间的中断。排错要点包括 master_link_status、master_last_io_seconds_ago、以及 netstat 的连接状态。
通过快速调整网络抖动以及提升心跳间隔，可以缓解此类问题，同时通过 redis-cli 的诊断命令监控复制端口的连通性与延迟。
netstat -tunp | grep 6379
redis-cli -p 6379 INFO replication
5.2 场景回顾：主从数据不一致
数据不一致往往与 偏移量积累、RDB/AOF 同步策略冲突、或 跨数据中心的延迟有关。要点是对比 role、master_link_status、以及 repl_offset 等复制指标。
在这类场景下，通常需要进行 手动数据对齐、以及必要时执行 重新全量同步，以确保主从数据一致性。
import redis
master = redis.Redis(host='redis-master', port=6379)
slave = redis.Redis(host='redis-slave', port=6379)
print(slave.info('replication').get('master_repl_offset'))
print(master.info('replication').get('master_repl_offset'))
