Redis主从同步问题解决方案

Redis主从数据不一致是生产环境中极易被低估却后果严重的隐患，看似简单的replicaof命令切换或重连操作，往往因未清空脏数据、忽略master_replid/offset校验、误判PSYNC2协议行为而失效；真正可靠的修复需主动干预：提前验证复制状态、必要时手动清空从库或彻底重启并重建RDB、结合RDB二进制比对与多维度key级校验确认一致性，同时通过调优fork性能、启用无盘同步、错峰同步等策略严控全量同步对主库的冲击——每一步都关乎数据可信度与服务稳定性，容不得“以为重连就等于重同步”的侥幸。

从库数据不一致时，slaveof 命令不能乱用

Redis 5.0+ 已废弃 slaveof，改用 replicaof；但更关键的是：直接执行 replicaof no one 再 replicaof ，**不会清空从库现有数据**，只是切换复制源——如果原数据已错，新同步仍基于错误的偏移量或 RDB 快照，可能跳过修复。

常见误操作是以为“重连=重同步”，结果从库继续提供脏数据。真正触发全量同步（即清空本地数据、拉取新 RDB）的前提是：从库当前没有正在运行的复制流，且 master_replid 和 offset 与主库不匹配。

• 执行前先 INFO replication 查看 master_replid 和 master_repl_offset，确认是否和主库一致
• 若从库写入过（如手动 CONFIG SET slave-read-only no 后写入），必须先 FLUSHALL 或 FLUSHDB 清空，否则全量同步后仍混有旧脏数据
• 主库需开启 repl-diskless-sync no（默认），否则从库在接收 RDB 时若断连，可能残留半截文件导致后续同步失败

PSYNC2 协议下，从库无法自动降级为全量同步的典型场景

Redis 2.8+ 默认启用 PSYNC2，支持部分重同步（partial resync）。但当从库断连太久、主库 repl-backlog-size 不够大，或主库重启过导致 run_id 变更，从库发 PSYNC ? -1 请求会被拒，返回 -ERR 并 fallback 到全量同步——但这个过程不可控，且依赖主库 backlog 缓冲区是否还存着对应 offset 的命令流。

真正需要强制全量同步时，不能等它“自动发生”，而应主动破坏同步状态：

• 在从库执行 DEBUG RELOAD（仅限开发/测试环境），会清空内存并重新加载 RDB，同时重置复制状态
• 生产环境更稳妥的做法：停掉从库进程 → 删除 dump.rdb 和 aof 文件 → 启动并配置 replicaof → 此时必走全量同步
• 注意主库 repl-backlog-ttl 默认 3600 秒，超时后 backlog 被释放，从库即使只断连 1 小时也可能被迫全量同步

主从复制中断后，如何验证数据一致性而非只看 connected_slaves

connected_slaves 显示为 1 只说明 TCP 连接建立成功，不代表数据实时一致。真正要确认，得比对主从两端的逻辑状态：

• 用 redis-cli --rdb /tmp/dump_master.rdb -h --rdb 和 redis-cli --rdb /tmp/dump_slave.rdb -h --rdb 分别导出 RDB，再用 diff 或 rdiff 工具比对二进制内容（注意排除 timestamp 字段）
• 对关键 key 执行 MEMORY USAGE + OBJECT ENCODING + TTL 三重校验，比单纯 GET 更能发现底层结构差异
• 若启用了 AOF，检查主从 aof_current_rewrite_time_sec 和 aof_buffer_length 是否持续增长且差值稳定；突增可能意味着从库在重放大量 backlog，但尚未追平

全量同步期间主库性能抖动明显，该怎么压

RDB 生成是 fork() 子进程完成的，若主库内存大（比如 >10GB），fork() 会阻塞主线程数百毫秒甚至秒级，同时子进程写磁盘也会争抢 I/O。这不是“能不能同步”的问题，而是“会不会拖垮线上服务”的问题。

• 调大 vm.overcommit_memory = 1（Linux），避免 fork 失败；配合 echo 1 > /proc/sys/vm/overcommit_ratio 控制内存分配策略
• 主库启用 rdb-save-incremental-fsync yes，让子进程分批 fsync，降低单次 I/O 峰值
• 从库配置 repl-diskless-sync-delay 5，等待更多从库一起接入，合并成一次 diskless 同步（但要求主库也开 repl-diskless-sync yes）
• 最彻底的解法：把全量同步窗口挪到低峰期，并提前用 BGSAVE 手动生成 RDB，再通过 rsync 推送到从库，最后用 redis-server --appendonly yes --appendfilename appendonly.aof /path/to/dump.rdb 启动（需关闭 AOF 重写竞争）

全量同步不是“点一下就完事”的操作，它的触发时机、路径选择、资源隔离，每一步都直接影响主库可用性和数据可信度。尤其在跨机房或高延迟链路下，一次不干净的同步可能埋下数小时的数据偏差隐患。

好了，本文到此结束，带大家了解了《Redis主从同步问题解决方案》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！