mysql复制核心是主库binlog记录变更、从库i/o线程拉取写入relay log、sql线程重放执行；延迟主因包括网络、主库写压、从库单线程等，优化需综合架构（如gtid、半同步）、配置与硬件。

replication buffer 溢出导致命令丢失

主库在全量同步或网络抖动期间，会把新写入命令暂存在 replication buffer 中，等从库重连后补发。但这个 buffer 是固定大小（默认 1MB），一旦写入速度持续超过从库消费能力，buffer 就会溢出——溢出部分的命令直接丢弃，不会重传。

此时从库即使重连，也只能触发部分同步（PSYNC），但因缺失的 offset 已不可达，最终 fallback 到全量同步；若未 fallback，则数据永久不一致。

• 检查方式：INFO replication 中查看 repl_backlog_active 是否为 1，再比对 repl_backlog_size 和实际写入压力
• 调优建议：将 repl-backlog-size 设为写峰值 QPS × 命令平均大小 × 预期最大断连秒数，例如 50MB 是较稳妥的生产起点
• 注意：repl-backlog-ttl 默认 3600 秒，超时后 backlog 被清空，也会导致无法部分同步

从库执行阻塞命令拖慢复制流

Redis 复制是单线程串行执行命令的。如果从库正在运行一个耗时命令（如 KEYS *、大 HGETALL、LRANGE biglist 0 -1），后续所有来自主库的写命令都会排队等待，造成 slave_repl_offset 滞后，且滞后值持续扩大。

这不是网络问题，而是从库自身负载导致的“假延迟”——监控看到 master_repl_offset - slave_repl_offset 差值很大，但 connected_slaves 仍是 1。

• 定位方法：在从库执行 CLIENT LIST，找 cmd= 非空且 idle 值大的连接；或用 SLOWLOG GET 5 查最近慢查询
• 规避手段：禁用所有阻塞命令（如改用 SCAN）、限制大 key 操作频次、避免在从库执行运维类读命令
• 严重时可临时 CONFIG SET slave-read-only yes 并重启从库，防止人为误操作加剧阻塞

主从 run_id 不匹配强制降级为全量同步

从库重启或主库重启后，run_id 会变更。从库重连时携带旧 run_id 和当前 offset 发起 PSYNC，主库发现 run_id 不匹配，直接拒绝部分同步，返回 FULLRESYNC。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

这本身不是“无法同步”，而是“无法增量同步”。但若此时主库正忙于生成 RDB 或磁盘 IO 高，就会表现为从库卡在 LOADING 状态，看起来像“部分命令没过来”。

• 验证方式：对比主从 INFO server 中的 run_id 字段是否一致
• 注意：仅修改 replicaof 地址端口不会重置 run_id；只有主库进程重启才会变
• 不要依赖 replicaof no one && replicaof ip port 来“刷新同步”，它不改变 run_id，也不清空已有数据，极易残留脏数据

从库被设为可写且执行了本地写入

一旦执行过 CONFIG SET slave-read-only no，从库就允许写入。哪怕只写了一条 SET foo bar，也会导致：① 该 key 的后续主库写入被覆盖；② 主从 run_id 和 offset 逻辑错乱；③ 复制流可能静默跳过冲突命令，不再报错。

这种污染不可逆——重启从库后 slave-read-only 会恢复为 yes，但已写入的数据还在，且与主库 diverge。

• 紧急检查：CONFIG GET slave-read-only + INFO replication 中看是否有 slave_read_only:0 或历史写入痕迹
• 修复底线：必须停从库 → 删除 dump.rdb 和 appendonly.aof → 清空 temp-*.rdb → 启动并 replicaof → 等待 slave_repl_offset == master_repl_offset
• 长期防护：在配置文件中显式写死 slave-read-only yes，并用 CONFIG REWRITE 固化

真正难排查的是那种“同步流看似正常、offset 在涨、但个别 key 始终不更新”的情况——大概率是 run_id 错配后 fallback 全量同步失败，或从库 AOF/RDB 加载时被 maxmemory 策略提前截断，这些细节一旦漏查，修复动作就白做了。