全量复制发生时，需先确认info replication中master_sync_in_progress:1为真，再结合repl_backlog_active、repl_backlog_histlen、offset差值等指标综合判断；常见真实原因为repl-timeout过短、fork失败、client-output-buffer-limit溢出或psync降级，而非repl-backlog-ttl设置不当。
全量复制发生时，先确认是不是真在全量同步
看到 INFO replication 里 master_sync_in_progress:1 才算真正进入全量复制；如果只是 loading:1 或 master_link_status:down，那可能是从节点刚启动、RDB加载中，或连接已断——别急着调参，先分清阶段。
关键指标要一起看：master_repl_offset 和 slave_repl_offset 差值是否归零后突然暴涨？repl_backlog_histlen 是否长期为 0？如果是，说明积压缓冲区根本没生效，不是“部分同步失败”，而是“压根没机会走部分同步”。
检查 repl-backlog-size 是否被实际使用
很多集群改了 repl-backlog-size 却没效果，是因为主节点上没有活跃从节点连接——这个缓冲区是懒分配的，首个从节点连上来才初始化。所以：repl_backlog_active:0 就代表它当前没启用，配置再大也没用。
- 执行
redis-cli INFO replication | grep repl_backlog，确认repl_backlog_active是 1 - 观察
repl_backlog_histlen是否随写入持续增长（比如每秒增几万），而不是卡在 0 或极小值（如 128） - 如果
repl_backlog_first_byte_offset > slave_repl_offset，说明从节点想续传的位置早已被覆盖，PSYNC 必然失败
排查触发全量复制的真实原因，而非只盯 repl-backlog-ttl
repl-backlog-ttl 只控制“所有从节点断开后 backlog 缓冲区保留多久”，对正在同步的从节点完全无效。频繁全量复制几乎从不因它太小引起，真正常见原因有：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
repl-timeout设得太短（如默认 60 秒），网络抖动超时即断连，从节点重连只能全量 - 主节点 fork 失败（
latest_fork_usec超过repl-timeout），导致 PSYNC 请求被拒，降级为 SYNC - 从节点重启后用
SLAVEOF命令重连，而非带 offset 的 PSYNC 协议 - client-output-buffer-limit slave 触发溢出，主节点主动断开连接，强制全量重试
查日志重点找：Partial resync not possible (no cached master)（说明 master 没缓存 runid+offset）、Connection with slave lost（缓冲区溢出）、Failed to fork（fork 失败）。
验证网络与缓冲区是否匹配业务写入节奏
估算 repl-backlog-size 不能拍脑袋：拿主节点峰值写入带宽 × 断连容忍时长。例如每秒写入 4.2MB，希望扛住 90 秒断连，至少设 repl-backlog-size 390000000（≈372MB）。
但设大了也未必安全——若 client-output-buffer-limit slave 的软限制时间（第三个参数）没同步拉长，缓冲区照样会在 60 秒内被清空断连。所以必须同步调整：
- 查当前值：
CONFIG GET client-output-buffer-limit，确认 slave 行第三个数字 ≥repl-timeout - 例如
repl-timeout 90，则至少设为slave 536870912 134217728 90 - 调完立刻
CONFIG REWRITE，否则重启后失效
真正难处理的不是参数怎么填，而是写入峰值、网络抖动 P95、缓冲区容量、timeout 四者之间必须闭环验证——差一个环节，全量复制就会反复发生。
