默认为no,从节点同步或断连时拒绝读请求并返回“SYNC with master in progress”错误;设为yes则继续返回旧数据,但存在一致性风险。

默认情况下,Redis 从节点在主从同步过程中会拒绝大多数客户端查询请求,只允许 INFO 和 SLAVEOF 命令,这是由配置项 slave-serve-stale-data 控制的——它默认为 no,而非 yes。
为什么从节点同步时返回“SYNC with master in progress”
当 slave-serve-stale-data no 时,Redis 从节点处于以下任一状态就会拒绝读请求:
- 刚启动,尚未完成首次全量同步(RDB 加载中)
- 与 master 断连后正在重连并发起
PSYNC或SYNC - RDB 文件接收完成、但仍在逐条重放 AOF 缓存命令(即 repl-backlog 中的积压命令)
此时所有非管理类命令(如 GET、HGETALL)都会收到错误响应:SYNC with master in progress。这不是 bug,是 Redis 主动阻塞行为,目的是避免业务误读到不一致或空数据。
如何让从节点同步时继续提供旧数据服务
只需将从节点配置文件中的 slave-serve-stale-data 改为 yes,然后重启或热重载配置:
slave-serve-stale-data yes
生效后,从节点会在以下场景继续响应查询:
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 同步进行中(RDB 传输/加载、AOF 命令重放阶段)→ 返回上一次同步完成时的数据
- 与 master 失联且未开启
replica-announce-ip等哨兵感知机制 → 继续用最后已知状态服务 - 首次同步完成前(即内存为空)→ 返回空值或对应类型的默认响应(如
GET返回(nil))
注意:该设置不影响写操作——从节点始终只读(除非手动关闭 slave-read-only yes)。
设成 yes 后要注意哪些实际影响
slave-serve-stale-data yes 虽提升可用性,但引入了明确的数据一致性风险:
- 主从延迟较大时,客户端可能读到数秒甚至数分钟前的老数据
- 若 master 故障且未启用 Sentinel / Cluster,从节点无法自动升级,
yes会让业务持续读取停滞数据,掩盖故障 - 某些强一致性场景(如库存扣减后立即查余额)可能因读到 stale data 导致逻辑错乱
- 日志中不再出现 “SYNC with master in progress” 错误,排查同步卡顿问题会更困难
生产环境建议结合监控使用:通过 INFO replication 中的 master_sync_in_progress、slave_repl_offset 和 master_repl_offset 差值,判断是否长期处于 stale 状态。
动态修改 vs 配置文件修改的区别
两种方式都有效,但行为略有差异:
- 运行时执行
CONFIG SET slave-serve-stale-data yes→ 立即生效,无需重启,但重启后失效(除非写入配置文件) - 修改
redis.conf并CONFIG REWRITE或重启 → 持久化,推荐用于生产部署 - 若用
SLAVEOF命令临时切换主从,CONFIG SET的值仍保留,不会被重置
真正容易被忽略的是:这个配置只作用于从节点自身,对它的下游从节点(级联复制)无影响——每层都需单独配置。

















