诊断前的准备与环境检查
确认版本与环境一致性
在本次Redis 主从复制故障排查与修复实战中，第一步要做到<版本一致性与<部署环境一致性的核对，避免版本差异带来的行为差异影响排查结果。若主从节点版本不同，可能导致复制握手失败或功能特性的差异化表现，进而掩盖真正的故障根因。通过统一的镜像或配置管理工具能够快速实现跨节点的一致性。
此外，建立一个基线变量集合也是关键环节。包括CPU、内存、磁盘I/O、网络往返时间以及 replication 的基本状态等指标。将这些作为后续故障对比的对比基准，可以迅速判断异常是否来自资源紧张、网络抖动还是配置错误。基线指标越完整，诊断速度越快。
# 查看本机 Redis 版本
redis-server --version
# 查看任一节点的详细版本与运行信息
redis-cli -h master-host INFO server
redis-cli -h slave-host INFO server
时间同步与网络连通性
在主从复制场景中，时间同步的偏差会对复制日志的时间戳和偏移计算造成影响，因此应确保所有节点的系统时钟趋于一致。通过NTP服务或 chrony 进行全网级别的时间同步，是排查工作的基础环节。缺乏同步的时钟跳动可能引起从节点连接中断或偏移追赶失败。
同时，网络连通性直接决定主从握手是否稳定。先检查网络分区、丢包率和端口可达性，确保 master 与 replica 之间的基础通信无阻。针对生产环境，可以使用简单的连通性测试来快速定位网络层面问题。若网络不通，排除网络故障后再回到复制层面的排查上。
# 确认主从间的时钟对齐情况（示例）
ntpq -p
# 测试主从 6379 端口的连通性
nc -vz master-host 6379
# 基本网络连通性诊断
ping -c 4 master-host
常见故障场景与排查思路
主从断连的典型原因
当出现主从断连时，首先要确认<master_link_status与<master_status等字段的状态。若从节点长期保持 master_link_status: down 或 master_sync_in_progress: 1，往往意味着网络、身份验证、端口隔离或配置错误是核心原因。通过对比 master 与 replica 的 INFO replication 信息，可以快速定位是网络、认证、还是数据偏移导致的断连。
此外，观察repl_offset 与 master_repl_offset之间的差值，可以判断复制是否仍在进行偏移追赶，或者已被中断。若复制信道未建立，应该首先排查认证字段（如 requirepass、masterauth）以及防火墙策略。对比状态能帮助快速定位到具体问题点。
# 可能的从节点复制信息示例
role:slave
master_host:192.168.1.100
master_port:6379
master_link_status: up
master_last_io_seconds_ago: 2
master_repl_offset: 2147483647
在确认存在问题后，可以通过直接重指向主节点来验证是否是临时性问题导致的断连。尝试使用 REPLICAOF 或 REPLICAOF NO ONE 等命令进行临时切换测试，以验证网络与认证是否恢复正常。
# 重新指向主节点，测试网络与主从握手
redis-cli -h replica-host REPLICAOF 192.168.1.100 6379
# 如需临时将从节点提升为单机，后续再重新挂载主节点
redis-cli -h replica-host REPLICAOF NO ONE
网络分区与防火墙导致的同步中断
网络分区是导致主从复制中断最常见的外部因素之一。若发现 master_link_status 为 down，首先排查网络分区、ACL、NAT、防火墙和主机间端口映射是否正确。网络分区会导致从节点无法接收新的增量更新，进而产生长时间的不一致。
在排查路由和防火墙后，务必测试复制端口的端到端连通性。部分云环境或虚拟化平台可能对跨 AZ 的流量进行限速或丢包，需结合运营商诊断工具进行确认。只有网络稳定后，复制流程才有机会重新建立并保持一致性。
# 查看防火墙与端口策略
iptables -L -n
ufw status
# 测试从 replica 到 master 的端口 6379 的连通性
telnet master-host 6379
# 基本网络健康检查（示例）
ss -tlnp | grep 6379
配置不一致与授权问题
配置不一致或授权问题是导致复制失败的另一大类原因。常见错误包括 requirepass 与 masterauth 不匹配、从节点未正确设定 REPLICAOF、TLS/认证相关证书问题等。统一的 配置模板 能显著降低此类故障发生概率。
在排查阶段，建议将主从的 redis.conf 与启动参数进行对比，确保 slave-serve-stale-data、replica-read-only、notify-keyspace-events 等字段的一致性。必要时重新加载配置并重启节点以确保改动生效。
# 示例：常见的认证与主从配置片段
requirepass your-secure-pass
masterauth your-master-auth-token
replicaof 192.168.1.100 6379
# 也可使用新版本的命令：
REPLICAOF 192.168.1.100 6379
快速修复与验证流程
手动修复步骤与降级/切换策略
在出现复制故障时，快速的修复路径之一是手动重新建立主从关系或临时降级以保证可用性。REPLICAOF（或 REPLICAOF NO ONE）命令可用于快速重置从节点的主从关系，随后再重新指向正确的主节点，以触发重新的增量复制与数据同步。
另外，在网络极端或节点不可用的情况下，短时间内可考虑将从节点切换为独立服务以保障只读请求的可用性，待网络或主节点恢复后再完成回滚与重新同步。此类操作应在短时间内完成，且确保数据的一致性后再对外宣布上线状态。
# 将从节点重新指向主节点
redis-cli -h replica-host REPLICAOF 192.168.1.100 6379
# 若要将从节点改回单机模式，执行
redis-cli -h replica-host REPLICAOF NO ONE
数据一致性校验与快速修复
完成重指向后，应对比 master_repl_offset 与 repl_offset 的差距，确保从节点能够跟上主节点的写入速率，并且不再出现长时间的“正在同步”的状态。通过 INFO replication 可以直观地观察复制进度以及当前状态。若出现数据偏离，需触发手动全量或部分数据同步。
同时，检查持久化状态（RDB/AOF）能帮助确认在故障修复后数据是否被正确持久化。通过 INFO persistence 可以查看 RDB/AOF 现状，确保在修复过程中数据未被意外丢失。必要时，重新执行数据快照或重放 AOF 文件以修复数据不一致的问题。
# 数据一致性与持久化状态检查
redis-cli -h master-host INFO replication
redis-cli -h master-host INFO persistence
再次验证并上线
修复步骤完成后，务必进行全面的验证，确保主从关系稳定、复制延迟降至可接受范围、并且线上请求已可用。再次执行 INFO replication 并关注 master_link_status、master_last_io_seconds_ago、repl_backlog_active 等字段的表现，确认复制链路恢复正常。
上线前应执行滚动健康检查：对从节点进行流量测试、对主节点的写入速率与延迟进行监控，确保在高负载场景下仍能保持稳定性。整合上述步骤，即可实现从诊断到快速修复的完整流程，确保 Redis 主从复制在故障后尽快恢复。
# 最终验证示例
redis-cli -h master-host INFO replication
redis-cli -h replica-host INFO replication
# 如一切正常，master_link_status 应为 up，master_last_io_seconds_ago 小于等于 3-5 秒
