replica-ignore-maxmemory 是 redis 6.0+ 从节点忽略自身 maxmemory 限制的配置，设为 yes 后从节点不主动淘汰 key，避免主从数据不一致。需在从节点配置文件中静态设置并重启生效。
replica-ignore-maxmemory 是什么，为什么需要它
Redis 主从同步时，如果从节点（replica）启用了 maxmemory 且配置了淘汰策略（如 volatile-lru），它可能在同步过程中主动驱逐 key——哪怕这些 key 还没被主节点标记为过期或淘汰。这会导致从节点数据与主节点不一致，严重时引发读取脏数据、应用逻辑异常甚至缓存雪崩。
replica-ignore-maxmemory 就是为解决这个问题而生的开关：设为 yes 后，从节点会完全忽略自己的 maxmemory 和 maxmemory-policy 配置，所有内存管理行为交由主节点决定。它不是“禁用淘汰”，而是“让副本不自主淘汰”。
如何正确启用 replica-ignore-maxmemory
该配置仅在 Redis 6.0+ 生效，且必须在从节点上设置（主节点设了无效）。它不能通过 CONFIG SET 动态修改，必须写入配置文件并重启生效。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 编辑从节点的
redis.conf，添加或修改：replica-ignore-maxmemory yes
- 确保从节点已配置
replicaof <master-ip><master-port></master-port></master-ip>或通过REPLICAOF命令建立主从关系 - 确认主节点开启了
maxmemory，否则即使从节点不淘汰，主节点也可能因 OOM 被系统 kill - 重启从节点后，可通过
CONFIG GET replica-ignore-maxmemory验证是否生效
不设 replica-ignore-maxmemory 的典型错误现象
当从节点未启用该选项，且自身 maxmemory 小于主节点或同步积压较大时，容易出现：
- 从节点日志中频繁出现
evicted_keys计数上涨，但主节点无对应淘汰记录 - 客户端从从节点读到
nil，而主节点仍能查到该 key（尤其在 TTL 接近但未过期时） -
INFO replication显示master_repl_offset和slave_repl_offset差距稳定，但INFO memory中used_memory_peak持续波动 - 使用
redis-cli --rdb导出从节点 RDB 时，发现 key 数量明显少于主节点
要注意的兼容性与副作用
这个配置看似简单，但有几个硬约束和隐含影响：
- 仅适用于 Redis 6.0 及以上版本；5.x 及更早版本不识别该配置项，设了也无效
- 启用后，从节点内存可能持续增长直至接近系统内存上限——它不再主动释放，全靠主节点同步删除或过期来间接回收
- 若主节点故障切换为新主，原从节点升主后会沿用旧配置（
replica-ignore-maxmemory yes），但此时它已不是 replica，该配置失效，且不会自动加载新的maxmemory-policy，需人工干预 - 哨兵（Sentinel）或 Cluster 模式下，failover 后的新从节点默认不会继承该配置，必须确保配置文件中已固化
真正要稳住主从一致性，光靠这个开关不够——得配合合理的 maxmemory 预留（比如从节点比主节点多留 15% 内存）、监控 mem_fragmentation_ratio 和 evicted_keys 指标，并在扩容前评估 RDB/AOF 加载阶段的内存峰值。
