主从同步中断根本原因是缓冲区被冲垮或版本/配置不兼容：必须同时调大repl-backlog-size和client-output-buffer-limit，确保增量同步能力与发送速率匹配；严格校验主从Redis小版本一致性；延长repl-timeout至300秒避免误断，并排查网络、SELinux等隐蔽障碍。
主从同步中断根本不是“断连”问题，而是缓冲区被冲垮或版本/配置不兼容导致的硬性失败
repl-backlog-size 和 client-output-buffer-limit 必须同时调大
高压下主节点一边生成 RDB，一边还要把增量命令写进复制积压缓冲区（repl-backlog-size），同时还要把全量数据发给从节点——这三件事共用同一个输出缓冲区。默认 client-output-buffer-limit slave 256mb 64mb 60 完全扛不住。
- 先用
config set client-output-buffer-limit "slave 1024mb 512mb 120"立即生效，避免主节点因缓存满直接断开从节点连接 - 再设
config set repl-backlog-size 1024mb，确保从节点重连后能命中增量同步，不反复触发全量同步 - 这两项必须一起改，只调一个没用：
repl-backlog-size决定“能追多远”，client-output-buffer-limit决定“能发多快”，高压下两者都容易溢出
检查 Redis 版本是否完全一致
集群中任意一对主从节点版本不一致（比如主是 7.2.5，从是 7.0.12），就会在握手阶段失败，日志里只显示 MASTER SLAVE sync: receiving ... bytes from master 然后静默断开，不报错也不重试。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 登录每个节点执行
redis-cli info server | grep redis_version，逐个比对 - 不要只看大版本号（如都是 7.x），小版本差异（如 7.2.0 vs 7.2.5）也可能导致协议字段解析失败
- 升级时必须先停从节点，换二进制，清空
dump.rdb和appendonly.aof，再重启；不能仅靠slaveof命令热切
repl-timeout 过短会掩盖真实问题
默认 repl-timeout 60 在高压场景下极易误判：主节点正在 dump RDB 或网络抖动 2 秒，就直接断开连接，然后从节点立刻重试——形成“断开→重连→失败→再断开”的死循环。
- 把
repl-timeout改成300（5 分钟），给 RDB 生成和传输留出足够窗口 - 注意：这个值不是越大越好，超过 300 秒说明底层已存在严重瓶颈（如磁盘 I/O 拖累 bgsave），得查
INFO persistence中的rdb_last_bgsave_time_sec - 修改后用
config rewrite写入配置文件，否则重启失效
真正卡住的点往往藏在细节里：比如从节点的 bind 配置没放开、防火墙只放行了客户端端口没放同步端口、甚至 SELinux 默认拦截了跨节点 socket 通信——这些都不会出现在 Redis 日志里，但会让 cluster nodes 显示节点在线，INFO replication 却始终是 master_link_status:down。
