主库被复制请求压垮表现为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 的内核参数适配。 
