因全局驱逐策略问题，迁移单个Redis数据库至新实例的最优方案

核心结论 #

Redis确实不支持单数据库级别的驱逐策略配置，maxmemory-policy是全局生效参数，所有数据库共享同一规则，无法单独给db4禁用键驱逐。

你的方案可行性分析 #

方案1：副本迁移（推荐，无停机） #

完全可行，步骤及注意事项：

• 部署新Redis实例，配置充足内存，设置maxmemory-policy noeviction，将原实例设为主节点，新实例作为从节点启动同步。
• 通过INFO replication确认同步完成（master_link_status为up，sync_full标记完成）。
• 切换应用流量到新实例，之后断开主从关系，新实例转为独立主节点。
• 注意：确保切换时应用读写的原子性，新实例内存需能完全容纳db4数据，避免后续再次触发内存不足。

方案2：RDB导出迁移（有停机） #

可行，但存在业务中断：

• 停止原实例写入（可通过CONFIG SET stop-writes-on-bgsave-error yes后执行SAVE，或直接暂停应用写入），生成RDB文件。
• 将RDB文件复制到新实例目录，配置maxmemory-policy noeviction后启动新实例。
• 登录新实例，执行FLUSHDB清空除db4外的所有数据库，再切换应用指向新实例。
• 缺点：需要停止写入，仅适合能接受短时间停机的场景。

其他迁移策略 #

渐进式键迁移（低停机） #

通过MIGRATE命令分批迁移db4的键到新实例：

• 编写脚本循环执行：
  1. 在原实例执行SCAN 0 MATCH * COUNT 100获取db4的一批键。
  2. 对每个键执行MIGRATE new_redis_host new_redis_port "" 4 5000 REPLACE（5000为超时毫秒数，REPLACE用于覆盖新实例已存在的重复键）。
  3. 直到SCAN返回游标0，完成全量迁移。
• 注意：迁移前可短暂暂停应用写入，迁移最后一批数据，避免遗漏迁移过程中新写入的键。

工具辅助迁移（无停机，高可用性） #

使用Redis迁移工具（如RedisShake）完成db4数据迁移：

• 部署配置好noeviction的新实例，启动RedisShake，指定原实例为源、新实例为目标，仅同步db4的数据。
• 同步完成后切换应用流量到新实例，停止迁移工具。
• 优势：几乎无停机，支持增量同步，适合对可用性要求高的场景。

内容的提问来源于stack exchange，提问作者timpone