停机迁移用“业务中断”换“操作简单”，在线迁移用“技术复杂度”换“业务零感知”，对于大多数核心数据库或线上服务，在线迁移的长期代价远低于停机迁移，但前提是工具选型正确与回滚预案完备。
这是很多团队在规划迁移时最先纠结的问题，下面不绕弯子，直接从业务代价、风险敞口、实操路径三个维度拆开讲清楚。
停机迁移和在线迁移的区别到底在哪
工作模式上的根本差异
停机迁移的逻辑是“先停服，再搬家，后开业”，整个过程里，业务对外完全不可用，用户访问直接失败或看到维护页，在线迁移的逻辑则是“边营业，边搬家，最后切流量”，业务全程保持可用状态,数据在后台持续同步。
从团队感受来说，停机迁移更像一次计划内的“全麻手术”，病人（业务）躺平了，医生（运维）可以从容操作，在线迁移则像“心脏搭桥手术”，心脏（业务）还在跳动，医生必须保证血流（数据流）不断,操作精度要求高得多。
业务影响面对比
| 对比维度 | 停机迁移 | 在线迁移 |
|---|---|---|
| 业务可用性 | 全程中断 | 基本无感知 |
| 操作窗口 | 需预留完整空窗期 | 随时可执行 |
| 技术门槛 | 较低 | 较高 |
| 回滚复杂度 | 简单，重启旧库即可 | 复杂，需处理增量数据 |
| 对用户影响 | 直接不可用 | 几乎为零 |
| 典型适用场景 | 内部系统、低峰期小库 | 核心交易库、7×24小时业务 |
行业共识认为，对于承载核心交易或对外服务的数据库，停机迁移造成的用户流失和品牌信任损失，往往远超技术团队节省的那点操作成本，很多团队只算了“停机多久能搬完”，却没算“停机那段时间用户去了哪”。
数据库停机迁移的代价有多大
直接代价：停机窗口与业务中断
停机迁移最直观的代价就是停机窗口。网站迁移停机多久算正常没有统一答案，但业内一般以“业务可容忍的中断时间”为准，电商平台大促前夕、SaaS系统月初结算日、游戏开服活动期间,这些时段完全不能碰。
假设一次迁移需要6小时停机，这6小时内的订单、注册、支付、客服工单全部被切断，积压的请求在恢复后集中涌入，又可能造成第二轮雪崩，据统计，相当一部分迁移故障并非发生在迁移过程中，而是发生在恢复服务后的半小时内,原因就是流量突刺和缓存穿透。
停机时长越长，代价不是线性增长，而是指数级恶化，业务恢复后，你还要花额外时间安抚客户、补救数据、处理投诉，这笔“善后账”常常被迁移方案里的“预估工时”一笔带过。
间接代价：回滚压力与团队心理
停机迁移还有一笔隐藏成本：没有回头路可走，一旦停服，你只能向前，如果迁移中途发现数据不一致或版本不兼容，回滚意味着整个停机窗口翻倍,团队在巨大时间压力下容易做出错误判断。
业内专家指出，多数停机迁移事故的根因，并非技术本身，而是“不敢停更久”导致的仓促决策，团队在半夜两点、业务方不断催促“好了没有”的背景下，放松了校验步骤,把未验证的配置直接带上了生产环境。
停机期间业务方、客服部门、用户侧的压力会全部涌向运维团队，这种心理压力难以量化，但确实存在,而且会直接影响操作判断。
在线迁移的工具选型与实操路径
在线迁移并非所有场景都适用，但只要你不想承担停机代价，这个方向就必须考虑。在线迁移工具推荐的逻辑很简单：选社区活跃、支持断点续传、具备数据校验能力的方案，不要选“能跑就行”的脚本。
开源方案与云厂商托管方案怎么选
- 开源方案：MySQL系可用gh-ost、pt-osc，PostgreSQL系可用pglogical、repmgr，Redis系可用redis-shake，这些工具支持增量同步,迁移过程中源库照常读写。
- 云厂商托管方案：简米云DTS、酷番云DTS、AWS DMS，都提供结构迁移+全量迁移+增量同步的完整链路，好处是自带监控告警和断点续传，坏处是数据库迁移服务价格按迁移数据量和同步链路时长计费,长跑任务成本并不低。
一次典型在线迁移的步骤拆解
以MySQL迁移到新实例为例，流程可以概括为“五步走”：
- 第一步：配置增量同步，先在源库上开启binlog，并确认binlog_format为ROW，然后配置同步工具,让目标库追平源库数据。
- 第二步：全量数据校验，用pt-table-checksum或自研脚本比对源与目标的数据一致性，这一步最耗时间，也是很多人偷懒跳过的一步。跳过校验的在线迁移，本质上是把风险留给了未来某个不确定的深夜。
- 第三步：灰度切读，把只读流量切一部分到新库，观察慢查询、报错率、连接数,此时源库和目标库同时在服务读请求。
- 第四步：写入切换，在业务低峰期，短暂禁止源库写入，等待增量同步位点追上，然后将写流量切到新库，这个“禁止写入”的窗口通常以秒甚至毫秒计,远短于停机迁移的分钟级或小时级窗口。
- 第五步：观察与兜底，切换后至少观察24小时，保持源库不销毁，等到确认新库稳定、备份完整,再释放源库资源。
迁移过程中的命令示例如下,方便你直接对照操作：
# 使用redis-shake同步Redis数据 ./redis-shake -type sync -conf redis-shake.conf # 使用pt-table-checksum校验MySQL数据一致性 pt-table-checksum --databases=your_db --tables=your_table
什么情况下必须回退
在线迁移的回退条件比停机迁移苛刻，一旦写流量切换到新库后才发现性能瓶颈或数据缺失，回退不只是“再把流量切回去”那么简单新库上新增的数据必须反向同步回源库,否则旧库上的数据是残缺的。
在线迁移的代价发生在“迁移后”而非“迁移中”，你要为回退场景预留额外的同步通道，并且提前验证反向同步的可用性，多数情况下，团队愿意为了“不中断业务”接受这个复杂度，因为相比用户流失,这点维护成本完全可以接受。
迁移前必须做的三件事
不管选停机还是在线，这三件事不做,迁移就是赌博。
第一件事：先做全量备份
这听起来像废话，但确实有团队因为“源库磁盘不够，先删了过期binlog再迁移”而丢失增量数据，备份必须独立存储，且要演练过恢复流程。备份恢复不了就等于没有备份。
第二件事：压测目标库性能
新库性能未必比旧库好，如果目标库的磁盘类型是HDD而非SSD，或者实例规格配置不足，迁移后慢查询数量可能暴涨，建议用sysbench或JMeter的测试结果来对比迁移前后的响应时间，而不是只看“能不能连通”。
第三件事：明确回滚条件和责任人
回滚不是技术问题，是决策问题，谁有权决定回滚？回滚的触发条件是延迟超过多少毫秒，还是错误率超过哪个阈值？这些必须在迁移开始前写成书面清单，没有阈值定义的回滚机制，在真实故障发生时大概率变成“再观察五分钟”。
业务代价的最终权衡
停机迁移的代价是确定性的、可预见的业务中断；在线迁移的代价是不确定性的、需要持续投入的运维成本，对于内部管理后台、测试环境、非核心报表库，停机迁移完全够用，挑凌晨低峰期执行即可，但对于线上交易、用户登录、消息推送这类链路，选择在线迁移意味着把“业务可用性”放在最高优先级,这个代价是值得的。
停机迁移和在线迁移的常见问题答疑
停机迁移和在线迁移哪个更便宜？
单纯看工具成本，停机迁移更便宜，它只需要一次性的数据导出导入，不涉及持续的增量同步链路费用，但把业务中断损失算进去就反过来了，比如一个日均订单量较大的电商库，停机6小时损失的订单佣金和用户信任，可能抵得上在线迁移工具一年的订阅费用。小库看工具成本，大库看停机损失。
网站迁移停机多久算正常？
取决于你的业务容忍度，常规内部系统预留2到4小时是常见做法；对外服务的核心库，行业普遍要求停机窗口控制在15分钟以内，超过30分钟的停机已经算重大事故，需要提前报备管理层，如果预估迁移时间超过1小时，建议直接切换为在线迁移方案,并同步测试增量数据同步的正确性。
在线迁移期间源库性能会受影响吗？
会，增量同步工具需要读取源库的binlog或WAL日志，执行全量数据扫描时也会占用源库的磁盘IO和CPU资源，在业务高峰期，这种资源占用可能会放大慢查询，建议在迁移前把源库的sync_binlog和innodb_flush_log_at_trx_commit参数临时调整为更安全的配置,迁移结束后再改回业务常态值。