从库要不要自己淘汰
从库默认不按自己的内存上限淘汰数据，而是跟着主库的复制流走，这就是 replica-ignore-maxmemory 默认为 yes 的含义。这样能保证主从数据一致，但代价是从库内存可能超出你给它设的上限；想让从库自己兜住内存，可以改成 no，但要清楚由此带来的读一致性代价。
基本信息
| 默认值 | yes，从库忽略自身内存上限 |
|---|---|
| 改为 no | 从库按自己的 maxmemory 执行淘汰 |
| 代价 | 从库自行淘汰会造成主从数据不一致 |
| 常规做法 | 扩容与读流量治理，而不是让从库自行淘汰 |
典型使用场景
- 从库内存水位明显高于主库，判断差异来自哪里
- 从库规格较小、只承担读扩展时的内存策略评估
- 排查从库被系统 OOM 杀掉的根因
- 评估读请求是否依赖从库数据的完整性
- 多副本架构下统一各节点的内存策略
查看与对比
查看与对比
# 查看从库是否忽略自身上限（默认 yes）
redis-cli CONFIG GET replica-ignore-maxmemory
# 需要从库自己兜住内存时改为 no，代价是可能出现主从不一致的读结果
redis-cli CONFIG SET replica-ignore-maxmemory no
# 比较主从水位与复制状态，判断差异来源
redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human'
redis-cli INFO replication | grep -E 'role|master_link_status|slave_repl_offset'内存差异来源
| 来源 | 表现 | 排查方式 |
|---|---|---|
| 复制积压 | 从库侧输出缓冲增长 | 看 INFO replication 的偏移与链路状态 |
| 大量读请求 | 客户端输出缓冲被放大 | 看 clients 段的缓冲相关字段 |
| 参数不一致 | 数据相同但水位不同 | 核对 maxmemory 与淘汰策略 |
| 从库自行淘汰 | 主从数据出现差异 | 确认 replica-ignore-maxmemory 是否被改成 no |
| 持久化与 fork | 快照期间写时复制抬高占用 | 看持久化状态与 fork 耗时 |
从库内存治理的常规手段是扩容与治理读流量，而不是让从库自行淘汰；一旦让从库淘汰，读到的主从数据不一致就会变成常态，读一致性的预期要重新写清楚。
「从库内存比主库高」本身不代表故障：复制积压、客户端输出缓冲、快照期间的写时复制都会抬高从库占用，先分清属于哪一类再动手。