1. 故障定位与日志分析
日志收集与关键日志定位
本文围绕 Redis 主从复制故障排查全流程指南：从定位日志到修复策略的一站式排错展开，第一步是对日志进行全面分析。日志的完整性、时间戳一致性和覆盖范围是判断问题发生时序的关键。要确保master与slave日志都可获取、且时间线一致，才能快速拼接故障全貌。错误码、断开信息、连接重置是最直观的线索。
在生产环境中应建立统一的日志聚合与留存策略，集中式日志可以显著缩短定位时间；结合INFO/ERROR/WARN等级分布，能快速锁定问题阶段。将日志输出到日志管理系统后，结合以下要点定位：INFO replication、MASTER、slave state、连接断开等字段。
# 常用日志定位示例
grep -i -E "master|slave|replication|error|disconnect|connection|timeout" /var/log/redis/redis-server.log | tail -n 200
常用日志字段解释
在分析 INFO replication 输出时，关注字段如 master_link_status、slave_read_only、repl_backlog 等。若出现 master_link_status:up，通常表示连接正常；若出现 master_link_down、master_sync_in_progress，则提示不同阶段的问题。数据传输阶段的延迟也往往在日志中体现。
对日志进行分段归档时，应记录最近一次SYNC/PSYNC的时间戳、断开后重连的模式，以及 重试间隔 是否异常增大。这些信息共同指向故障节点与网络的关系。
故障触发的典型信号
常见信号包括网络分区导致的连接断开、主从延迟拉高、RDB/AOF加载错误、以及 从节点无法接收/应用日志等情况。这些信号往往在 INFO replication 与 日志系统 同时出现，提供了故障的时间轴与可验证的证据。
2. 主从复制机制与常见故障点
复制流程与数据对齐要点
在 Redis 的主从复制架构中，主节点作为数据源，从节点作为数据消费者进行数据复制。SYNC、PSYNC、RDB快照、AOF重写等阶段共同完成初次对齐与后续增量传输。理解这些阶段有助于快速判断延迟、数据错配的原因。本文强调的是“从主到从”的数据流向和时间点。
当复制出现问题时，通常需关注 master_replid、master_last_io_seconds_ago、slave_repl_offset 等状态指标，以及从节点的 read_only 状态是否异常。通过对比两端的 rdb_checksum 或 AOF 发生的时间点，可以快速定位数据不同步的范围。
# 查看当前复制状态
redis-cli INFO replication
# 查看从节点状态
redis-cli -h -p INFO replication
常见故障点分类
常见故障点包括<网络抖动导致连接断开、主从心跳超时、REPLICAOF 指令误用、从节点的 RDB/AOF 不一致等。这些故障往往伴随特定日志与状态变化，需要在诊断清单中按维度逐项排查。
为每种故障点建立快速诊断清单，确保排错时能覆盖到 连接、数据流、日志、配置四个维度，并在排查过程中持续更新状态和证据链。
3. 现场排错步骤全流程
阶段一：确认角色错位与连接状态
第一阶段的核心是确认主从角色与连接状态，必要时重新指定主从关系。通过 REPLICAOF 指令查看并修正主从关系，确保当前从节点正确追随主节点。关注输出中的 master_link_status、master_host、master_port。
# 查看主从关系
redis-cli INFO replication# 将从节点指向正确主节点（如需要）
redis-cli --raw REPLICAOF # 旧版本为 SLAVEOF
如果输出中出现 READONLY、link down、master_link_down 等状态，应立即定位网络层或中间设备的阻断，并在日志中记录网络事件的时间点以备追溯。
阶段二：网络层与防火墙排查
网络抖动、NAT、ACL、端口屏蔽都可能打断复制通路。优先排查端口连通性与防火墙策略，结合中间设备日志与网络工具提供诊断证据。通过 tcpdump、ping、mtr 等工具建立网络层证据链，确保复制通路在故障时段是可用的。
# 简单连通性测试
ping -c 4
telnet # 抓包查看
tcpdump -i eth0 port 6379 -nn -s0 -c 1000
阶段三：复制状态自检与重试策略
在长期延迟或大数据量场景下，关注 master_last_io_seconds_ago、slave_repl_offset、master_replid 等字段，必要时尝试部分重同步（PSYNC）来恢复增量同步。
# 查看复制状态细节
redis-cli INFO replication# 触发部分重同步（示意，需满足条件）
redis-cli -h -p REPLICAOF # 取消复制，改为本地独立运行（排查网络与主从机制）
redis-cli -h -p REPLICAOF NO ONE
4. 修复策略与执行计划
快速修复动作
在确定故障点后，执行快速修复动作包括 修复网络、重新建立主从连接、重启节点、清理阻塞连接等。务必在修复前完成 数据备份，避免二次数据损失。
# 重新建立从节点与主节点的连接
redis-cli -h -p REPLICAOF # 如网络暂不可用，尝试短期中断复制，后续再恢复
redis-cli -h -p REPLICAOF NO ONE
数据一致性修复策略
修复后需进行数据一致性检查，交叉对比主从节点的 INFO replication、rdb_checksum、aof_checksum，以及 master_repl_offset 与 slave_repl_offset 的对齐情况。若存在不一致，需通过重新对齐或重放日志来恢复。
# 数据一致性比对示例
redis-cli -h -p INFO all | grep -E "redis_version|repl_backlog|master_repl_offset|slave_repl_offset"
redis-cli -h -p INFO all | grep -E "redis_version|repl_backlog|master_repl_offset|slave_repl_offset"
5. 预防与演练
备份与快照策略
定期快照与增量备份是降低故障影响的关键。需要确保备份可用于快速恢复，并且在恢复时能确保主从数据的一致性。对于高可用场景，建议结合 RDB+AOF 的双备方案，以提高灾难恢复的魄力。
在主从复制场景中，确保主节点的备份策略覆盖 RDB/AOF 的组合，以实现从节点在断连后快速回放到一致状态。
灾难演练与回放
定期进行灾难演练，模拟网络分区、主从断连、数据错配等场景，验证排错流程的有效性，并记录每次演练的时间与结果，为持续改进提供证据链。
