Redis主从复制卡住时，应先检查slowlog是否有堆积：执行SLOWLOG GET 10查看慢查询，重点关注耗时超client-output-buffer-limit slave阈值（默认60秒）的KEYS、SCAN、SUNION等命令，以及>100ms的EXEC/EVAL；再用CLIENT LIST筛选qbuf>1MB或obl>64MB的从库连接；最后确认repl-backlog-size是否足够（建议≥64MB），避免断连后触发全量同步加剧阻塞。
Redis主从复制卡住时，先看 slowlog 是否有堆积
主从复制阻塞常表现为从库 master_link_status 变为 down，或复制偏移量长期不增长。这时不能只盯 INFO replication，得确认主库是否在执行耗时命令拖慢了复制缓冲区刷新——slowlog 就是第一线索。
执行 SLOWLOG GET 10 查最近 10 条慢查询，重点关注：
• 耗时超过 client-output-buffer-limit slave 设置的写入超时阈值（默认 60 秒）
• 命令类型为 KEYS、SCAN（未加 COUNT）、大集合 SUNION/ZINTERSTORE 等
- 若
slowlog中出现大量 >100ms 的EXEC或EVAL，说明事务或 Lua 脚本阻塞了主线程，复制命令无法及时写入 repl-backlog -
SLOWLOG RESET不解决根本问题，但可清空干扰项，方便复现后对比 - 注意：慢日志默认只记录 >10ms 的命令，如需捕获更细粒度，启动时加参数
--slowlog-log-slower-than 5000（单位微秒）
用 CLIENT LIST 找出复制连接异常的客户端
CLIENT LIST 返回所有连接信息，主从复制中，从库连接的 flags 字段含 S（slave），但仅靠这个不够。真正要筛的是那些 qbuf（查询缓冲区）或 obl（输出缓冲区）持续增大的连接。
-
qbuf > 1048576（1MB）且长时间不降：说明从库网络延迟高或处理慢，主库还在往其输入缓冲区塞命令 -
obl > 67108864（64MB）：已触发client-output-buffer-limit slave的硬限制，主库会主动断开该从库连接 - 检查
age和idle：若age很大但idle也很大，可能是从库假死，主库尚未检测到心跳超时
可配合 CLIENT LIST | grep 'flags=S' | awk '{print ,,}' 快速提取关键字段（qbuf、obl、age）做监控比对。
映技派
一个AI人工智能工具资源库，优选有用、高效的gpt人工智能AI工具
下载
复制阻塞和 repl-backlog 大小强相关
主库靠环形缓冲区 repl-backlog 给断连重连的从库补数据。一旦从库断开时间超过 repl-backlog 覆盖时长，就会触发全量同步（psync fullresync），而全量同步期间主库 fork 子进程生成 RDB，可能引发内存暴涨和 CPU 尖峰，进一步加剧阻塞。
- 用
CONFIG GET repl-backlog-size查当前大小，默认 1MB；对写入频繁的实例，建议设为至少 64MB（CONFIG SET repl-backlog-size 67108864） -
repl-backlog-active为 0 表示未启用，常见于配置未生效或 Redis 版本过低（ - 注意：增大
repl-backlog-size会增加主库内存占用，但远小于一次全量同步的开销
别忽略 client-output-buffer-limit slave 的隐式影响
这个配置控制主库对每个从库输出缓冲区的软硬限制，格式为 client-output-buffer-limit slave 。它不像 slowlog 那样显眼，却是复制中断最直接的“判决者”。
- 默认值
client-output-buffer-limit slave 256mb 64mb 60：缓冲区达 64MB 持续 60 秒，主库强制断连 - 若从库处理慢（如磁盘 IO 差、CPU 过载），
obl很快触顶，此时调大hard_limit只是延缓断连，治标不治本 - 真正该做的是定位从库瓶颈：用
redis-cli -h INFO commandstats看cmdstat*exec或cmdstat*eval的调用耗时是否异常
复制阻塞很少是单点问题，slowlog 揭示主库负载，CLIENT LIST 暴露连接状态，而两个 buffer 配置决定了系统能容忍多大偏差——三者必须交叉验证，否则容易把从库慢归因为主库卡顿，或反过来。