新主节点淘汰key异常是因replica-ignore-maxmemory yes残留，需立即config set replica-ignore-maxmemory no，再同步maxmemory和maxmemory-policy，否则内存策略失效且无告警。
新主节点突然开始淘汰 key，大概率是 replica-ignore-maxmemory 残留
原从节点升主后，replica-ignore-maxmemory yes 这个配置不会自动失效，也不会被 CONFIG REWRITE 写入磁盘——它只是“静默无效”。此时 Redis 退回到默认行为：maxmemory 0（不限制）+ maxmemory-policy noeviction。一旦实际内存接近物理上限，新主收到写入就会直接拒绝，报 (error) OOM command not allowed when used memory > 'maxmemory'. 或静默丢弃。
- 别只查
CONFIG GET maxmemory，要立刻执行redis-cli INFO memory | grep maxmemory确认maxmemory:字段是否为 0 - 运行时执行
CONFIG SET replica-ignore-maxmemory no是必须的第一步，否则后续设maxmemory和maxmemory-policy都不生效 - 如果用容器部署，检查挂载的
redis.conf是否仍含replica-ignore-maxmemory yes，该行在非 replica 角色下无意义，但容易误导运维
maxmemory 和 maxmemory-policy 必须和原主库完全一致
三个配置项必须同步：数值单位、大小写、格式全对齐。比如 2gb ≠ 2147483648，allkeys-lru ≠ AllKeys-LRU。生产环境尤其要避开 volatile-ttl：大量无 TTL 的 key 会让策略实质退化为 noeviction，等于没开淘汰。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
maxmemory建议统一用2gb这类可读格式，避免数字易错；单位大小写敏感（MB≠mb） -
maxmemory-policy必须在replica-ignore-maxmemory no之后设置，顺序错会导致策略加载失败 - 验证方式：执行
SET test_key "x" EX 300后，再DEBUG OBJECT test_key看是否成功；同时INFO stats | grep rejected_connections应为 0
自动化脚本里最容易漏掉的一步：升主后没重置 replica-ignore-maxmemory
多数 Sentinel / Cluster / 自研 failover 脚本只做 SLAVEOF NO ONE，却忘了清理这个残留配置。它不会报错、不写日志、也不影响当前运行——但下次该节点降级为从库时，会重新启用 replica-ignore-maxmemory yes，导致内存策略再次失效，而你根本收不到任何告警。
- 必须在 promote 成功后立即执行：
redis-cli CONFIG SET replica-ignore-maxmemory no - 紧接着设
CONFIG SET maxmemory 2gb和CONFIG SET maxmemory-policy allkeys-lru - 不要依赖
CONFIG REWRITE：它不会覆盖原始配置文件里的replica-ignore-maxmemory yes，只保存运行时 SET 的值
为什么不能等下次重启再修？
因为 replica-ignore-maxmemory yes 是运行时配置，重启后会从磁盘配置文件重新加载。如果你没改掉原始 redis.conf，或者容器镜像里固化了该配置，问题会在每次升主后重现。更危险的是：它不会触发 CONFIG GET 异常，也不会让 INFO memory 显示错误值——你只能靠写入失败或 rejected_connections 上升才发现。
