5步诊断法
步骤1：确认复制拓扑与角色分配
在进行Redis 主从复制故障排查时，第一步需要明确当前的复制拓扑与角色分配，以判断是否存在误配置或角色错位。通过 INFO replication 可以快速查看各节点的身份、连接状态，以及主从之间的偏移量与同步状态，帮助定位问题源头。
实际环境中，主从切换失败、某个从节点意外变为主节点等场景常见。请记录下主节点 IP/端口、从节点列表以及认证参数，这一信息是后续诊断与快速修复的关键。若需要快速预览，请在任意节点执行以下命令并关注输出的 role 与 connected_slaves 字段。
redis-cli -h -p INFO replication 步骤2：检查网络连通性与端口
网络连通性问题往往是导致复制中断的首要原因之一。请通过网络检测确认从节点能否稳定访问主节点的端口，同时排查防火墙和安全组是否阻塞。网络层的不稳定会直接使复制通道中断或延迟拉长。
确保网络连通性良好、端口开放、且没有中间设备强制关闭连接，这是稳定复制的基础。下列命令用于快速验证连通性与端口可达性。
# 检测主节点连通性
ping -c 4
# 测试主从端口是否对等开放
nc -zv 6379
# 查看从节点对主节点的 replication 状态
redis-cli -h -p 6379 INFO replication
步骤3：验证复制相关配置与认证
复制相关的配置项不正确或身份认证失败，都会导致从节点无法与主节点建立稳定的复制通道。请检查并确认 replicaof（旧版本可能为 slaveof）、masterauth、以及网络绑定等配置是否正确。
动态修改配置有助于在故障排查时快速重试：若需要，使用 CONFIG GET 查看当前配置，或使用 CONFIG SET 暂时调整参数，以验证是否由配置错误引发的问题。
# 查看当前复制相关配置
redis-cli -h -p 6379 CONFIG GET * | grep -E 'masterauth|replicaof|slaveof|bind|requirepass'
# 将从节点指向正确的主节点（如需要）
redis-cli -h -p 6379 REPLICAOF
# 如需认证，设置主节点认证参数
redis-cli -h -p 6379 CONFIG SET masterauth ''
步骤4：观察日志与复制状态
日志与复制状态是定位复制故障的重要线索。通过再次查看 INFO replication 输出，可以发现当前是否存在正在进行的主从同步、延迟情况、以及是否出现连接中断等现象。
关注的关键字段包括 role、master_sync_in_progress、master_last_io_seconds_ago、以及 slave_repl_offset 的差值。若出现 master_sync_in_progress 为真、或 master_last_io_seconds_ago 长时间大于 0，往往意味着网络、认证或数据同步存在问题。
redis-cli -h -p 6379 INFO replication
redis-cli -h -p 6379 INFO replication
步骤5：执行修复并验证
在明确问题根因后，执行相应的修复方案并对复制状态进行最终验证。常见的修复方向包括：修正拓扑、重建认证、以及触发重同步等。修复完成后，务必再次验证复制链路是否正常、偏移是否在可接受范围内，以及从节点能否正常读取数据。
确保在修复后再次建立稳定的 master–replica 通道，并通过实际数据读取校验数据一致性，这一步是避免回归问题的关键。
# 将从节点重新指向主节点（若需要重新触发全量重同步）
redis-cli -h -p 6379 REPLICAOF NO ONE
redis-cli -h -p 6379 REPLICAOF
# 验证复制状态
redis-cli -h -p 6379 INFO replication
# 如需测试数据一致性，请读取数据并对比
redis-cli -h -p 6379 GET some-key
常见原因
网络分区与防火墙
网络分区、ACL 限制或防火墙策略常导致主从节点之间的通信中断，进而使复制通道处于不可用状态。网络抖动也会引起复制拉取的延迟，导致从节点落后主节点一段时间。
处理要点包括检查网络连通性、确认安全组和防火墙规则的放通范围、以及确保跨机房/云区域的网络延迟在可接受范围内。必要时可通过本地时间保持同步、使用专用网络通道来降低抖动。
# 测试网络连通性与端口
nc -zv 6379
# 查看防火墙策略（示例，具体命令以系统为准）
sudo iptables -L -n
认证失败
主从之间的认证信息不一致也会导致无法建立稳定的复制连接。主从认证失败通常源于 masterauth 设置不一致、凭据变更未同步、或 requirepass/acl 相关配置变更后未同步。
解决策略包括确保从节点配置正确的 masterauth、必要时在从节点执行 CONFIG SET masterauth，并再次触发 REPLICAOF 来重新建立连接。
# 指定主节点认证信息
redis-cli -h -p 6379 CONFIG SET masterauth ''
# 重新建立复制关系
redis-cli -h -p 6379 REPLICAOF
主从数据不同步导致的偏移错位
当主从数据存在明显差异、或偏移量未同步时，复制链路可能出现错位，导致从节点读取到落后数据或数据不一致。使用 master_repl_offset 与 slave_repl_offset 的差值来评估是否存在错位。
解决办法通常包括触发全量同步或先断开再重新建立复制关系，以确保从节点从主节点完整重载数据。
# 查看主从偏移量
redis-cli -h -p 6379 INFO replication
redis-cli -h -p 6379 INFO replication
复制缓冲区大小与吞吐瓶颈
repl-backlog_size、repl_back_log 等参数的配置不足可能导致在高并发情形下复制缓冲区不足，进而引发复制延迟和丢失情况。
解决办法包括调整 backlog 的大小、提升网络吞吐、或增加主从之间的带宽与资源，从而降低复制延迟。
# 查看复制相关指标
redis-cli -h -p 6379 INFO replication
redis-cli -h -p 6379 INFO replication
版本差异与命令兼容性
主从复制在不同版本之间可能存在兼容性差异，升级或回滚导致的行为差异也会引发同步问题。需要确保主从节点的版本在兼容范围内，并关注版本相关的新特性与弃用项。
定期对环境进行版本对齐与变更评审，避免出现因为版本差异而引发的复制异常。
# 验证版本信息
redis-server -v
redis-cli --version
落地修复方案
统一网络与时钟同步
为了避免因为时钟漂移和网络抖动导致的复制错位，必须确保网络环境稳定并实现时钟同步。使用可靠的时间源，搭建稳定的时钟同步机制是关键。
NTP/Chrony 的时钟同步可以显著降低因时间偏差引发的复制问题，在故障排查中应优先完成时钟对齐。
# 使用 NTP 进行时间同步（示例）
sudo apt-get install -y ntpdate
sudo ntpdate time.nist.gov
# 或使用 chrony 的监控与源信息
chronyc sources -v
修复复制配置与认证
在确认网络无阻后，重点修复复制配置与认证，确保从节点能够稳定连接并完成数据同步。
将从节点正确指向主节点、并确认主从认证信息一致，这通常是恢复复制的核心步骤。
# 将从节点指向正确的主节点
redis-cli -h -p 6379 REPLICAOF
# 设置主节点认证信息，确保复制认证通过
redis-cli -h -p 6379 CONFIG SET masterauth ''
重新同步策略与快照
在主从数据差异较大或长期未同步的情况下，触发重新同步是常见做法。通过短暂断开复制关系再重新建立，可以触发从节点从主节点进行全量重载，确保数据一致性。
通过断开再重新指向主节点的方式触发全量重同步，是落地修复中常用的手段，同时要注意在重同步过程中对业务的影响及容量规划。
# 断开复制关系后再重新建立，以触发全量重同步
redis-cli -h -p 6379 REPLICAOF NO ONE
redis-cli -h -p 6379 REPLICAOF
监控与告警策略
建立持续的监控与告警，是防止复制问题再次发生的前置条件。通过采集 INFO replication 指标、复制延迟、以及网络健康状态，设定合理的告警阈值，能在问题初期就被发现。
将 master_last_io_seconds_ago、slave_repl_offset 与 offset 差值等关键指标纳入告警规则，以便在数据延迟超出阈值时触发告警并自动执行诊断流程。
# 监控要点示例（伪代码，实际接入监控系统时使用对应 API/Metric）
# 条件：master_last_io_seconds_ago > 30 或 相对偏移量超出阈值
# 触发自动化诊断脚本或告警
故障后测试用例与回滚计划
完成修复后，应通过覆盖性测试确保复制链路恢复正常，并制定明确的回滚计划以防止新变更引入风险。
验证复制是否正常、数据是否可读，以及在不同场景下的回滚可行性，是避免再次出现同类问题的关键。
# 验证复制是否已恢复
redis-cli -h -p 6379 INFO replication
# 读取数据以验证一致性
redis-cli -h -p 6379 GET some-key
# 若需要回滚，请参考业务影响评估文档并执行对应操作
