主库被复制请求压垮表现为cpu和网络打满、从库卡在sync/psync：需错峰同步、调大repl-backlog-size、扩容maxclients及ulimit、启用diskless sync并调优内核参数。

主库 CPU 和网络被打满，INFO replication 显示多个从库卡在 SYNC 或 PSYNC 状态

这是典型主库被复制请求压垮的表现：每次全量同步（SYNC）都会触发一次 bgsave，多个从库同时发起，主库频繁 fork 子进程 + 压缩 RDB + 发送大文件，CPU 和网卡直接飙高。

实操建议：

• 禁止让多个从库在同一时间发起首次同步——用 redis-cli -h <em>slave_ip</em> -p <em>port</em> CONFIG SET slave-serve-stale-data no 配合错峰上线，或人工控制 SLAVEOF 时间
• 确认主库启用了 repl-diskless-sync yes，避免磁盘 I/O 成瓶颈；但注意该模式依赖 socket 缓冲区，需同步调大 net.core.wmem_max 和 tcp_wmem
• 检查 repl-backlog-size 是否过小（默认 1MB），导致从库断连重连时无法走增量同步（PSYNC），被迫降级为全量同步——建议按主库每秒写入量 × 断连容忍秒数 × 2 估算，例如 5MB/s 写入、容忍 60 秒断连，至少设为 repl-backlog-size 60000000

slaveof 指令后主库日志狂刷 Connection with slave <em>ip:port</em> lost

这不是网络问题，而是主库主动拒绝了从库连接——常见于主库设置了 maxclients 限制，而每个从库连接会占用一个 client 连接数，且不计入 client-output-buffer-limit slave 的控制范围。

实操建议：

• 用 CONFIG GET maxclients 查主库当前上限，再用 CLIENT LIST | grep "flags=s" 统计真实从库连接数，两者相减即为剩余可用连接数
• 若从库数量 > 5，必须调大 maxclients，否则新从库连不上，老从库也可能因心跳超时被踢出
• 别只改 maxclients，还要同步检查系统级限制：ulimit -n 必须 ≥ Redis 配置值，否则 Redis 启动时会静默截断

从库数量从 3 增加到 8，主库延迟突增，master_repl_offset 和 slave_repl_offset 差值持续扩大

不是带宽不够，是主库单线程写命令 + 复制缓冲区竞争导致的“复制积压”。Redis 主库靠一个线程串行处理写命令并写入复制缓冲区，从库越多，缓冲区写入越频繁，主线程阻塞风险越高。

实操建议：

• 启用 repl-diskless-sync-delay 5（单位秒），让主库在收到第一个 PSYNC 请求后等待最多 5 秒，攒一批从库一起做无盘同步，减少 fork 次数
• 监控 instantaneous_ops_per_sec 和 total_commands_processed 增速，如果写入 QPS 超过 5k，建议停止横向扩从库，改用读写分离中间件（如 redis-shake 或 twemproxy）分流
• 禁用 tcp-nodelay no（即开启 Nagle 算法），对复制流量有害——必须设为 tcp-nodelay yes，否则小包堆积加剧延迟

从库升级为新主库后，原主库重启连不上，报错 Master is currently unable to SYNC

这是主库重启后未清空自身复制元数据导致的：它仍认为自己是旧主，保留着过期的 run_id 和偏移量，而新主已切换身份，拒绝接受旧主作为从库。

实操建议：

• 主库重启前，先执行 DEBUG RELOAD 或手动删掉 dump.rdb 和 appendonly.aof（如果 AOF 开启），确保启动时不加载旧复制状态
• 更稳妥的做法是：主库重启后，立刻执行 REPLICAOF NO ONE 清除所有复制配置，再 REPLICAOF <em>new_master_ip</em> <em>port</em> 重新建立关系
• 切勿依赖 slave-announce-ip 自动发现——跨机房或容器环境容易解析错 IP，务必显式指定新主地址

从库数量不是越多越好，真正影响主库负载的是「同步时机」和「连接管理」，而不是数字本身。很多人调完 repl-timeout 就以为解决了，其实最常被忽略的是 maxclients 和系统 ulimit 的匹配，以及 diskless sync 的内核参数适配。