换机迁移的两条路
换机迁移有两条常见路径。第一条是停机迁移：老机执行一次后台快照，确认完成后把文件拷到新机，按与原机一致的配置启动，再核对数据。第二条是近乎不停机的做法：新机先作为从库挂到老机，等复制追平后停止写入、把新机提升为主库，再切换流量。后者把停机窗口压缩到切换的瞬间，代价是过程中需要管理主从关系与偏移对齐。
基本信息
| 快照迁移 | 需要停机窗口，步骤简单直观 |
|---|---|
| 从库迁移 | 停机窗口极短，依赖复制追平 |
| 核对手段 | DBSIZE 对比加业务抽样 |
| 关键前置 | 新机配置与老机逐项对齐 |
| 收尾 | 切换流量后观察一段时间再下线老机 |
典型使用场景
- 服务器到期或硬件更换时的整机迁移
- 跨机房或跨云搬迁，与流量切换方案配合
- 版本升级：新机部署新版本，追平后一次性切换
- 配置标准化：借迁移把历史遗留参数一并纠正
- 演练迁移流程，验证回滚路径是否真的可行
从库迁移思路
从库迁移思路
# 新机启动后先挂为从库
redis-cli REPLICAOF <老机IP> 6379
redis-cli INFO replication | grep -E 'master_link_status|master_last_io_seconds_ago'
redis-cli DBSIZE # 与老机对比键数量
# 追平并停写之后再提升
redis-cli REPLICAOF NO ONE
redis-cli INFO replication | grep role # 确认已成为主库
redis-cli INFO keyspace # 核对数据规模两种方式对比
| 方式 | 停机窗口 | 适用场景 |
|---|---|---|
| 快照迁移 | 等于拷贝与启动耗时 | 数据量不大，可安排停机窗口 |
| 从库迁移 | 仅切换瞬间 | 不允许停机、数据量大的场景 |
| 共同要求 | 配置对齐与数据核对 | 缺一不可，否则迁移后行为漂移 |
| 回滚准备 | 保留老机与旧数据 | 切换异常时可以快速回退 |
从库迁移的关键是切换前复制延迟接近零。延迟没有追平就提升，会丢掉尚未同步的写入；切换完成后也不要立刻下线老机，要留出一段可回滚的窗口。
新机上的内存上限、持久化配置、访问控制等参数必须与老机逐项对齐。不一致的典型表现是迁移后「性能突然变了」或「出现权限报错」，排查成本很高，不如迁移前逐条核对。