切换前必须同步maxmemory、maxmemory-policy、replica-ignore-maxmemory三个内存配置；升主后需立即执行CONFIG SET replica-ignore-maxmemory no，再设置正确的maxmemory和maxmemory-policy，否则残留配置将导致内存策略失效。
主从切换后从节点升主，为什么突然开始淘汰 key？
因为原从节点升主后仍保留 replica-ignore-maxmemory yes，但该配置在非 replica 角色下完全失效，且不会自动加载 maxmemory 和 maxmemory-policy —— 它会退回到 Redis 默认行为：maxmemory 0（64 位不限制）+ maxmemory-policy noeviction。此时若实际内存已接近物理上限，新主节点一接受写入就可能触发 OOM 或写失败。
切换前必须同步哪三个内存相关配置？
不能只改 maxmemory，这三个必须严格一致：
-
maxmemory：数值必须相同（单位、大小写、格式），建议统一用2gb这类可读格式，避免2147483648类易错数字 -
maxmemory-policy：策略名大小写敏感，allkeys-lru≠AllKeys-LRU；生产环境避开volatile-ttl，因大量无 TTL 的 key 会导致策略实质失效 -
replica-ignore-maxmemory：仅主从关系中有效；升主后该配置残留但不生效，需在切换脚本中显式清理或重置为no（否则下次降级再同步时可能误用）
如何验证切换后内存配置真正生效？
别只信 CONFIG GET 返回值，要交叉验证运行时行为：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 执行
redis-cli CONFIG GET maxmemory和CONFIG GET maxmemory-policy，确认值与预期一致 - 立刻跑
redis-cli INFO memory | grep -E "(used_memory|maxmemory|mem_fragmentation_ratio)"，检查maxmemory是否已反映在maxmemory字段（不是used_memory） - 手动触发一次写入（如
SET test_key "x" EX 300），再查INFO stats | grep rejected_connections—— 若为 0 且 key 可读，说明noeviction没意外激活
自动化切换脚本里最容易漏掉的一步
多数高可用方案（如 Redis Sentinel、Redis Cluster 或自研 failover 脚本）在 promote 后只做 SLAVEOF NO ONE，却忘了重载内存配置。真实风险点在于：replica-ignore-maxmemory yes 是运行时配置，不会随 CONFIG REWRITE 写入磁盘，也不会被 CONFIG SET 覆盖为 no —— 它只是“静默无效”。所以必须在升主后立即执行：
redis-cli CONFIG SET replica-ignore-maxmemory no
然后再设回你期望的 maxmemory 和 maxmemory-policy。否则下次它再被拉为从节点，会带着这个残留配置重新启用，而你根本不会收到任何日志告警。
