从本地迁移到阿里云国际，业务停机时间怎么控制？

“几十GB的数据迁移到云上，是不是必须停机几个小时？”

这是企业准备迁移上云时最担心的问题。

如果先停止本地业务，再开始复制服务器和数据库，停机时间确实可能很长。但在大多数生产迁移中，没有必要把所有工作都放在停机窗口内完成。

更合理的做法是：

先在业务正常运行时完成全量复制和持续同步，最后只在切换阶段短暂停止写入。

这样，停机窗口主要用于同步最后一小部分数据、验证结果和切换流量。

一、先明确允许停机多长时间

开始迁移前，客户需要先给出一个可以接受的业务中断时间。

例如：

内部系统可以停机2小时。
企业官网可以短暂停止发布，但页面不能打不开。
电商系统最多允许中断10分钟。
支付和订单系统不接受数据丢失。
测试环境可以安排半天维护。

不同目标会决定不同的迁移方式。

如果业务可以停机几个小时，可以在停止写入后一次性迁移。

如果只能停机几分钟，就需要提前完成全量迁移，并持续同步增量数据。

如果业务几乎不能中断，则可能需要双环境运行、灰度切换或者双向同步，项目复杂度也会明显提高。

先确定停机目标，再选择工具和架构，而不是先选迁移工具。

二、不要把服务器迁移和数据库迁移混在一起

一个完整业务通常包括多个部分：

操作系统
应用程序
配置文件
数据库
用户上传文件
缓存
定时任务
消息队列
域名和证书
外部接口
IP白名单

这些内容的迁移方式并不相同。

服务器系统可以通过镜像或服务器迁移工具复制；数据库更适合使用数据库迁移和增量同步工具；用户上传文件可以先做全量复制，再同步变化部分。

如果把所有内容都当成“复制一台服务器”，迁移后很容易出现数据库不一致、文件遗漏或者外部接口无法回调等问题。

三、先完成服务器全量复制

本地物理机或虚拟机迁移到阿里云国际ECS时，可以先在业务正常运行期间复制系统盘和数据盘。

阿里云Server Migration Center支持先进行全量迁移，再同步后续产生的增量数据，从而减少最终切换阶段需要复制的数据量。阿里云SMC服务器迁移说明

需要注意，服务器复制完成不代表业务已经可以直接上线。

迁移后的ECS还要检查：

操作系统能否正常启动。
网卡和磁盘是否正确识别。
应用服务是否能够启动。
软件许可证是否受硬件变化影响。
系统时间和时区是否正确。
原来的内网地址是否写死在配置中。
防火墙规则是否适合新的网络环境。
应用是否依赖本地存储设备。

这些验证工作都应该在正式切换前完成，而不是留到停机窗口内处理。

四、数据库采用全量加增量迁移

数据库通常是控制停机时间的关键。

如果只做一次全量迁移，迁移开始以后，本地数据库中新产生的数据不会自动出现在云上。为了保证一致性，只能在全量复制期间停止业务写入。

数据量越大，停机时间越长。

生产环境更适合采用三个阶段：

迁移数据库结构。
迁移已有的全量数据。
持续同步后续新增和修改的数据。

全量迁移期间，本地业务仍然可以继续运行。正式切换前，先暂停写入，等待最后的增量数据同步完成，再把应用连接切换到云数据库。

阿里云DTS也建议，对停机时间敏感的生产迁移同时选择结构、全量和增量迁移。只选择结构和全量迁移时，迁移期间产生的新数据不会自动复制。阿里云DTS迁移方式说明

五、关注增量同步延迟

配置了增量同步，不代表切换时一定没有数据差异。

在正式切换前，需要持续观察同步任务的延迟和状态。

如果源数据库在迁移期间进行大量批量更新、结构变更或者大事务操作，增量同步可能出现积压。

建议在切换前确认：

全量迁移已经完成。
增量任务处于正常状态。
同步延迟稳定在可接受范围。
没有迁移失败的表。
数据结构已经完成兼容性检查。
源库没有持续执行大型变更。
目标库的容量和性能足够。

如果同步延迟还有几十分钟，即使此时暂停业务，仍要等待积压数据处理完成，停机时间就会被拉长。

六、提前完成云上环境配置

停机窗口不应该用来临时创建VPC、安全组和负载均衡。

在正式迁移前，应提前准备好：

VPC和交换机
ECS实例
云数据库
安全组
负载均衡
NAT网关
公网IP
域名和证书
日志与监控
备份策略
告警联系人

还要确认本地与云上之间的迁移网络是否稳定。

如果通过公网传输大量数据，实际速度可能受到出口带宽、跨境线路和网络波动影响。数据量较大时，需要提前测算迁移时间，并评估VPN、专线或其他连接方式。

七、建立一套完整测试环境

正式切换前，应该让云上环境至少完成一次完整业务测试。

测试内容不应只有“首页能打开”，还要包括：

用户登录
注册和密码修改
数据查询
数据写入
文件上传与下载
邮件或短信发送
支付回调
第三方接口
定时任务
报表生成
数据库备份
日志采集
权限验证

很多迁移问题并不会出现在首页，而会出现在支付、回调、任务调度或者文件路径中。

如果测试需要使用真实数据，应提前做好权限控制和隐私保护，避免测试人员接触不必要的敏感信息。

八、检查写死的IP地址

迁移后，服务器的公网IP和私网IP通常会发生变化。

需要检查应用配置中是否写死了旧地址，例如：

数据库地址
Redis地址
文件服务器地址
内部API地址
支付回调地址
邮件服务器地址
第三方接口白名单
监控系统地址
运维登录白名单

如果第三方服务只允许原机房IP访问，迁移到阿里云国际后可能会被拒绝。

这类白名单修改通常需要外部供应商处理，不能等到正式切换当天才提交申请。

九、迁移定时任务要防止重复执行

本地服务器和云上服务器同时运行时，定时任务可能在两边重复执行。

这可能导致：

重复发送通知。
重复生成账单。
重复扣减库存。
重复同步数据。
重复执行备份。
重复调用第三方接口。

在迁移测试阶段，可以让云上定时任务保持关闭，或者使用明确的环境开关。

正式切换时，再按照迁移清单启用云上任务，并停止本地任务。

不要只依靠工作人员记忆，应该把每个定时任务的启停状态写入切换步骤。

十、提前降低DNS的TTL

如果最终通过修改DNS把用户流量切换到阿里云国际，应提前调整域名记录的TTL。

TTL越长，递归DNS和用户设备保留旧地址的时间可能越长。

如果在切换当天才降低TTL，之前已经缓存的记录仍然会按照原来的TTL继续生效。因此，通常需要在正式切换前提前调整。

但是，降低TTL也不能保证所有用户立即获得新地址。部分网络和本地设备可能继续使用旧缓存。

因此，在DNS传播期间，本地环境和云上环境可能会同时接收请求。

这段时间不能立即关闭旧服务器。

阿里云DNS迁移说明也建议，在解析传播完成之前保留原有服务，并持续监控新旧环境的流量。阿里云DNS平滑迁移说明

十一、正式切换前短暂停止写入

当服务器、应用和数据库都准备完成后，进入正式切换窗口。

推荐的处理顺序是：

通知相关业务人员进入维护窗口。
暂停发布和配置变更。
暂停用户写入或将系统切换为只读。
停止本地定时任务。
等待数据库增量同步追平。
同步最后一批文件。
执行数据一致性检查。
启动云上业务服务。
切换负载均衡或DNS。
执行业务冒烟测试。
持续观察错误率和订单数据。

真正需要停机的时间，主要集中在停止写入、同步最后增量和验证切换这几个步骤。

十二、数据验证不能只看总量

有时源库和目标库的表数量相同，但数据仍可能存在差异。

建议根据业务重要程度选择验证方式：

比较数据库和表数量。
比较关键表的记录数。
抽查最近新增的数据。
检查订单、用户和支付记录。
对关键字段进行校验。
检查自增ID或序列状态。
确认字符集、时区和排序规则。
验证大字段和特殊字符。
检查存储过程、触发器和定时事件。

对订单、财务和库存类数据，仅比较总行数通常不够，还需要进行更细的业务校验。

十三、必须提前写好回退方案

迁移失败时才讨论回退，通常已经太晚。

切换前应明确以下内容：

出现哪些问题必须回退。
谁负责做出回退决定。
回退需要多长时间。
DNS或负载均衡如何切回。
云上产生的新数据怎样处理。
本地环境是否仍然可用。
回退后怎样验证业务。

这里最容易忽略的是新数据。

如果流量已经切到云上，并且用户在云数据库中产生了新订单，此时简单把DNS切回本地，会造成这部分数据丢失。

因此，回退策略必须考虑数据方向。可以选择在观察期内保持反向同步，或者在回退前再次停止写入并把云上新增数据同步回本地。

回退不是把域名改回去这么简单，真正困难的是保证数据不分叉。

十四、不要过早关闭本地环境

切换成功后，也不建议立即删除本地服务器。

应当保留一个明确的观察期，持续检查：

页面错误率
接口响应时间
数据库连接数
慢查询
订单和支付数据
定时任务执行结果
文件上传下载
第三方回调
云资源费用

观察期间，可以把旧数据库保持只读，避免两边同时写入。

确认业务稳定、数据正确、回退窗口结束后，再按照计划下线旧环境。

十五、哪些业务适合灰度切换

如果系统支持，可以先把少量流量切换到阿里云国际。

例如：

先让内部员工访问新环境。
先切换一个低风险域名。
先让少量用户进入新系统。
先切换只读查询流量。
按地区或业务模块逐步迁移。

灰度切换能够提前发现性能和兼容性问题，减少一次性全量切换的风险。

但如果应用会话、缓存和数据库无法共享，强行拆分流量反而可能造成登录状态丢失或数据不一致。是否适合灰度，需要根据系统架构判断。

结语

控制迁移停机时间，关键不是让数据传输速度无限提高，而是把大部分工作放到正式切换之前。

可以把整个迁移过程拆成：

提前复制 → 持续同步 → 短暂停写 → 验证数据 → 切换流量 → 保留回退