服务器迁移是「看似简单、实则处处坑」的活。 本文给出一份我们 30+ 次迁移总结的清单。

迁移前：盘点与决策

  • 当前架构：单机 / 主从 / 集群 / 微服务
  • 目标架构：升级规格 / 跨云 / 容器化
  • 数据量：DB、文件、缓存、对象存储
  • 流量画像：QPS 高峰、带宽、CPU 峰值

迁移策略：四种选择

  1. 直接迁移（适用：内部系统、可停机）
  2. 双写过渡（适用：DB 同步，允许 1-2 分钟只读）
  3. 主从切换（适用：DB 主从架构，秒级切换）
  4. 灰度切流（适用：高可用架构，零停机）

数据库迁移：最关键的环节

  1. 全量备份：mysqldump / xtrabackup，上传新环境验证可恢复
  2. 数据校验：行数、表结构、checksum
  3. 增量同步：binlog 位置 / GTID，记录切换点
  4. 应用只读：迁移前 5 分钟切只读，避免增量数据丢失
  5. 最终同步：停止写入 → 等待 binlog 追平 → 切到新主

应用迁移：分批进行

  • 无状态服务：直接迁移，先迁
  • 有状态服务：依赖 DB 迁完后再迁
  • 定时任务：避免双机同时跑（用分布式锁 / 单独调度）
  • 文件存储：先迁历史数据，再迁增量

网络与 DNS

  • 提前降低 DNS TTL（300s → 60s）
  • 切换后保留旧环境 7-14 天作为回滚备份
  • 监控切流进度：5xx 率、慢请求、错误日志

回滚预案

  1. 应用回滚：镜像版本化（tag 化部署）
  2. DB 回滚：保留旧主实例只读，新主切换回旧主
  3. DNS 回滚：1 分钟生效（旧 TTL 60s）
  4. 文件回滚：OSS / S3 同步策略

迁移后验证

  • 核心链路跑一遍（注册、登录、下单、支付、回调）
  • 监控数据 24 小时观察
  • 通知团队进入 7 天观察期

需要专业迁移服务？查看部署迁移服务。