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 缓存和数据结构管理技能。通过自然语言操作 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 策略提前截断，这些细节一旦漏查，修复动作就白做了。
