Redis 6.2版本主从复制有哪些已知bug？-Redis-PHP中文网

redis 6.2 主从复制存在四大关键缺陷：exists命令在从节点不校验过期导致误返回1；全量同步期间从节点可能崩溃；slave-read-only被lua脚本绕过引发本地脏写；复制积压缓冲区内存泄漏。

redis 6.2版本主从复制有哪些已知bug？

Redis 6.2 主从复制中 EXISTS 命令返回不一致

Redis 6.2 修复了大部分过期 key 在从节点查询时返回 nil 的问题，但 EXISTS 命令仍存在逻辑遗漏：它不校验 key 是否已过期，只检查 key 是否存在于数据库结构中。因此即使该 key 在主节点上已过期（ttl 返回 -1），从节点执行 EXISTS 仍可能返回 1。

这个行为在 Redis 4.0.11 才被彻底修复，所以 Redis 6.2（发布于 2022 年）仍继承该问题。如果你用 EXISTS 判断锁是否存在、或做条件读取，且读的是从节点，结果不可靠。

实际表现：SET key val; EXPIRE key 1 后立即在从节点执行 EXISTS key → 返回 1；几秒后主节点已删该 key，但从节点仍返回 1
规避方式：避免在从节点使用 EXISTS 判断业务关键状态；必须用时，改用 GET + 判空（GET 在 6.2 中已返回 nil）
注意：该问题不影响主节点，也不影响 GET、HGET 等数据读取命令

全量复制期间副本节点可能崩溃

Redis 6.2 在执行全量同步（RDB 加载 + 增量命令回放）过程中，副本节点的命令处理模块存在资源调度缺陷，极端情况下（如大 RDB + 高频写入积压）会触发崩溃，错误日志通常含 Segmentation fault 或 assert failed。

这个问题在 Redis 8.6.2 中被明确修复（补丁编号 #redis-862-replica-crash-fix），但 6.2 本身未发布热修复版本。生产环境若频繁触发全量复制（如网络抖动、从节点重启），需警惕此风险。

典型诱因：主节点内存突增导致 bgsave 耗时变长，同时客户端持续写入，积压缓冲区（replication backlog）溢出，迫使从节点重试全量同步
临时缓解：增大 repl-backlog-size（默认 1MB），降低全量同步频率；监控 master_repl_offset - slave_repl_offset 差值，超阈值时主动干预
根本解法：升级到 8.6.2+，或至少跳过 6.2 直接使用 7.0+（7.0 起重构了复制命令执行路径）

从节点只读配置被绕过导致数据污染

slave-read-only yes 是默认配置，但 Redis 6.2 存在一个边界漏洞：当从节点启用 Lua 脚本且脚本内调用 EVAL 写命令（如 redis.call('SET',...)），即使 slave-read-only 为 yes，这些写操作仍会被执行并持久化到从节点 AOF/RDB —— 这直接破坏主从一致性。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

该问题并非设计意图，而是 6.2 对只读模式与脚本引擎的权限校验耦合不严所致。后续版本（7.0+）将脚本内的写命令统一拦截，并报错 READONLY You can't write against a read only replica.。

验证方式：在从节点执行 EVAL "return redis.call('SET','test','1')" 0，再查 GET test → 若返回 "1"，即已被污染
线上禁用：关闭 lua-time-limit 不是解法；必须确保所有从节点禁用 eval 权限（ACL 中显式 ~* &-@write），或升级
特别注意：该写入不会同步回主节点，也不会触发复制，纯属从节点本地脏数据

复制积压缓冲区未及时清理引发内存泄漏

Redis 6.2 的复制积压缓冲区（backlog）采用环形缓冲区实现，但其内存释放逻辑存在竞态：当多个从节点断连又重连、且偏移量分布分散时，主节点可能长期保留已无用的 backlog 数据块，导致 used_memory 持续上涨，最终 OOM。

该问题在 6.2 的生命周期内未被官方标记为 critical bug，但在高动态拓扑（如 K8s 环境下频繁扩缩从节点）中高频复现。Redis 8.6.2 明确修复了 backlog 内存回收的原子性判断逻辑。

监控指标：repl_backlog_active 为 1 但 repl_backlog_size 远大于 repl_backlog_histlen（历史长度）时，说明有内存浪费
临时手段：手动触发 CONFIG SET repl-backlog-size 1 再设回原值，可强制重建 backlog（需短暂阻塞主节点）
真正稳定方案：避免在 6.2 上部署动态伸缩的从节点集群；固定从节点数量 + 静态 IP + 长连接

Redis 6.2 的主从复制机制整体可用，但上述四点不是“边缘 case”，而是上线前必须验证的真实陷阱。尤其 EXISTS 行为和脚本写入问题，在分布式锁、幂等校验等场景下极易引发线上故障——它们藏在文档角落，却直接决定数据语义是否可信。