Redis集群数据同步失败如何排查_使用PSYNC命令检查主从偏移量与同步进度
PSYNC 命令返回 -ERR unknown command 怎么办
遇到这个错误，先别急着检查配置。问题的根源往往是版本不兼容：Redis 2.8 版本之前压根就不支持 PSYNC 命令。如果集群里混用了新旧版本的主从节点，从节点发起请求时，主节点会因为不认识这个命令而直接拒绝。
- 第一步，确认版本：在主节点和从节点上分别执行
redis-cli --version，确保双方版本都在 2.8 或以上。 - 第二步，处理旧版本：如果从节点是 2.6 或更早的版本，
PSYNC肯定行不通。这时只能降级使用老旧的SYNC命令进行全量同步，代价是失去了增量同步的能力。 - 第三步，启用SYNC：需要注意的是，Redis 4.0 之后默认禁用了
SYNC。如果必须使用，需要在从节点的配置文件中显式设置sla ve-serve-stale-data yes，然后重启服务。
执行 PSYNC 后返回 FULLRESYNC 但没后续数据流
看到 FULLRESYNC 响应，说明主节点已经同意进行全量同步，但从节点却卡在了接收 RDB 文件的阶段。这通常不是命令失败，而是数据传输环节遇到了瓶颈，比如网络或磁盘。
- 检查主节点日志：查看主节点的 Redis 日志，是否有
Failed to write to RDB file（写RDB文件失败）或fork() failed（fork进程失败）这类错误。 - 查看从节点同步状态：在从节点执行
redis-cli info replication，如果master_sync_in_progress字段长时间保持为 1，就说明同步进程卡住了。 - 确保磁盘空间充足：从节点的磁盘剩余空间，至少要达到主节点
used_memory_peak_human（内存使用峰值）的 1.5 倍。这为接收 RDB 文件以及可能的 AOF 缓冲区留出了余地。 - 注意RDB压缩：如果主节点配置了
rdbcompression no（关闭RDB压缩），生成的 RDB 文件体积会非常大，这会显著增加网络传输和磁盘写入的压力。
PSYNC 返回 +CONTINUE 但 offset 不更新
这种情况可以称为“假同步”：从节点收到了 +CONTINUE 响应，以为自己进入了高效的增量同步模式，但主节点的复制偏移量（offset）却迟迟没有更新。根本原因在于复制积压缓冲区（repl-backlog）出了问题。
- 检查主节点缓冲区：在主节点执行
info replication，关注repl_backlog_active（是否启用）和repl_backlog_size（缓冲区大小）。 - 计算偏移量差距：用主节点的
master_repl_offset减去从节点的sla ve_repl_offset。如果这个差值超过了repl_backlog_size，缓冲区里的历史命令已经被覆盖，增量同步无从谈起，必然会触发一次全量同步。 - 调整缓冲区大小：默认的
repl-backlog-size只有 1MB，在高写入场景下极易被快速填满。一个合理的设置公式是：写入峰值 QPS × 命令平均大小 × 60 秒，这能保证从节点在断连一分钟内仍能追赶。 - 留意日志警告：如果从节点日志里频繁出现
Partial resynchronization not possible（无法进行部分重同步），这就是缓冲区不够用的明确信号。
CLUSTER NODES 显示节点状态正常，但 INFO REPLICATION 的 master_link_status=down
这看起来有点矛盾，但其实揭示了 Redis 集群的两个独立层面：集群总线和数据复制。CLUSTER NODES 显示 connected，只意味着节点间的 Cluster Bus（集群总线，通常端口+10000）通信正常，并不代表用于数据复制的 TCP 连接（默认6379）也是通的。
- 确认TCP连接：在主节点上使用
netstat -tnp | grep :6379命令，查看是否有从节点 IP 建立的ESTABLISHED状态连接。 - 检查TCP保活：Redis 默认的
tcp-keepalive设置为 0（禁用）。在 NAT 或复杂的网络环境下，中间设备可能会静默地断开长时间空闲的连接，导致复制链路中断。 - 核对防火墙规则：防火墙可能放行了集群总线端口（如16379），但拦截了默认的数据复制端口（6379）。需要确保两个端口都畅通。
- 验证绑定地址：从节点配置中
sla veof指定的主节点地址，必须是主节点bind配置中明确绑定的IP之一。如果主节点只绑定了外部IP，而从节点用127.0.0.1或一个未绑定的网卡IP去连接，自然会失败。
最后要记住，判断复制是否健康，不能只看一次 PSYNC 的调用结果。关键在于持续观察 master_repl_offset 和 sla ve_repl_offset 这两个偏移量是否在同步增长、逐渐收敛。有两个特别容易被忽略的细节：一是前面提到的 repl-backlog 大小是否合理；二是主从节点之间的系统时钟是否存在较大漂移。时钟不同步会导致从节点发送的 PSYNC ? -1 请求被主节点拒绝，而错误日志里可能没有任何直接提示，让排查工作陷入僵局。
