开篇摘要

服务器迁移真正难的地方，从来不是"把文件传过去"，而是"传过去之后没人发现你搬了家"。一次迁移翻车，很少是因为复制命令写错参数，绝大多数是栽在没被列进清单的东西上：藏在 crontab 里的对账脚本、只在新 IP 上没加白名单的支付回调、被浏览器永久缓存的 301 跳转，还有最要命的那一类——新库已经写进去两百单，你才发现要往回滚。

这篇文章写给正准备把网站、数据库、业务系统从旧服务器或旧服务商搬到新环境的运维和技术负责人。下面这些是全文的核心判断，先看结论再看细节：

• 「不停机」不是零中断，而是用户可感知的中断足够短，并且每一步都能退回去。把目标定成"一点感觉都没有"，往往会逼着你做更复杂的双写方案，反而引入更多故障点。
• 迁移的时间预算，大头应该花在切换前。盘点、预演、压测、灰度，这些占了七成工作量；真到切换当晚，剩下的只是按剧本执行。
• "改完解析立刻生效"是误解。TTL 只是一个建议值，各地 Local DNS、运营商递归服务器、浏览器和操作系统自身都还有一层缓存。
• 数据库一旦被新库写入，回滚就不能简单丢弃新数据。这是整篇文章里最容易让人付出代价的一个坑，后面会单独拆开讲。
• 旧机至少保留 3 到 7 天再下线，这是经验建议，不是承诺，但它是你最后一条退路。

概念解析：先把"不停机"这件事定义清楚

三种停机口径，别混着谈

团队里讨论迁移方案时，最常出现的分歧其实是口径不一致。有人说的"不停机"是网站一直能打开，有人指的是订单不能中断，还有人认为只要没人投诉就算成功。动手之前，先把口径统一成三档：

第一档是读可用性，页面、图片、接口查询在任何时刻都能返回结果。这一类最容易保证，因为静态资源和只读接口可以在新旧两端同时挂着，切换流量即可。第二档是写可用性，注册、下单、支付、表单提交都不能断。这一档才是真正的难点，因为写请求一旦分散到两个数据源，一致性就成了绕不开的问题。第三档是数据零丢失，即切换过程中不丢任何一条已提交的数据。这一档要求你在切断旧库写入之前完成增量追平，并且能证明追平了。

把这三档写进迁移方案的第一页，让业务方签字确认。很多"迁移事故"其实不是事故，而是运维承诺了第一档、业务以为是第三档，最后预期错位。

迁移风险的三个真实来源

风险来源大致可以归成三类，每一类的应对思路完全不同。

解析层的风险来自缓存的不可控。你改了权威 DNS 的记录，但谁在什么时候看到新记录，你说了不算。递归 DNS、运营商缓存、企业内网 DNS、CDN 节点、浏览器自身的 DNS 缓存，任何一层都可能让部分用户在几十分钟里继续访问旧地址。

数据层的风险来自时间差。文件同步有滞后，数据库复制有延迟，附件和对象存储有同步窗口。你在某一秒切断写入，就必须保证这一秒之前的所有变更都已经在新侧落地，否则就是数据丢失。

状态层的风险最容易被忽略。会话（Session）、上传中的临时文件、队列里未消费的任务、正在执行的定时任务、连接中的 WebSocket、支付平台的异步回调，这些"活"的东西不会跟着文件一起搬家。新环境起来之后，这些状态要么丢了，要么重复执行。

哪些业务真的需要热迁移，哪些停机半小时反而更安全

不是所有系统都值得做双写。判断标准其实很朴素：写入是否涉及资金或者不可逆的业务结果。订单、支付、账务、库存扣减，这类业务做热迁移要慎之又慎；企业官网、内容站、文档中心、内部管理系统，停机半小时在凌晨做，风险远低于上一套复杂的双写架构。

还有一种情况我一般会劝人别硬扛：单体老系统，代码里到处是硬编码的绝对路径、写死的 IP、散落在多个配置文件里的连接串，而且没有人能说清全量依赖。这种系统做"不停机迁移"的成本，往往高于安排一次公告停机。把公告做好、时间选在低谷、把回滚准备充分，比硬上双写靠谱得多。

迁移前的信息盘点：一份不嫌长的清单

网络与解析

把旧机上所有对外提供服务的 IP 列出来，包括业务 IP、管理 IP、用于出站的 NAT 地址、IPv6 地址。域名方面不只记录 A 记录，还要把 CNAME、MX、TXT、NS、CAA 全部导出来对照，很多团队迁移完网站能打开，三天后才发现 SPF 记录里还是旧 IP，外发邮件全进垃圾箱。

解析记录的 TTL 要在迁移前就摸清当前值。如果现在是 3600 秒甚至更长，那降 TTL 的动作必须提前足够长时间做，否则等于没降。

证书与安全

SSL 证书要确认三件事：证书文件格式（Nginx 用的是 fullchain 合并文件还是分开的 crt 与 key）、私钥是否能在新机上还原（部分证书绑定了旧机的 CSR，需要重新签发）、以及是否有通配符或多域名证书漏拷。计划用新域名或新 IP 的场景，还要确认证书里的 SAN 是否覆盖。

防火墙规则要逐条导出：iptables 或 firewalld 的规则、云厂商安全组、Web 应用防火墙的 IP 白名单与黑名单、以及任何基于来源 IP 的访问限制。新环境的 IP 段和旧环境不同，这些规则照搬过去很可能把正常流量挡在门外。

外部依赖与白名单

这一项最耗时间，也最容易拖垮整个计划。第三方 API 的白名单——支付网关、短信平台、物流查询、银行或第三方代付接口、开放平台的回调 IP 授权——往往需要对方人工审核，有些平台的处理周期在一到三个工作日。迁移前两周就要把新 IP 提交上去，别等到切换前一天。

系统内部状态

定时任务用 crontab -l 导出，同时检查 /etc/cron.d、systemd timer、以及应用框架自带的调度器（比如 Laravel 的 schedule、Django 的 celery beat）。这些任务在新旧机同时运行时，后果是重复扣款、重复发信、重复生成报表。

还要记录：环境变量与配置文件里写死的地址、本地 hosts 文件、日志收集 agent 的配置、监控探针的注册信息、对象存储的挂载点、以及任何形式的内部服务发现地址。

邮件相关记录

邮件是迁移后最容易悄悄出问题的一环。除了 MX 记录，还要处理 SPF（把新 IP 加进 ip4 机制）、DKIM（选择器记录要一并迁移）、DMARC 策略，以及反向解析 PTR。反向解析通常需要服务商在机房侧设置，不是你在 DNS 面板里能改的，这一项必须提前跟服务商工单确认。另外提醒一句，不少机房默认限制 25 端口出站，如果你的业务自己发信，要在选型阶段就确认清楚。

备案接入信息

如果目标节点在中国大陆，就涉及 ICP 备案的接入变更。常见做法是在新接入商的备案系统里提交接入申请，由新接入商做核验，再报管局审核。这里必须说明：实际要求、流程、材料清单与审核时长，以管局要求与服务商流程为准，不同省份、不同时期的要求会有差异，不要照搬别人去年走过的流程。迁移排期时，备案环节要留出足够的缓冲，别让备案卡住整个项目。

停机窗口怎么算：TTL 与解析生效的不确定性

关于 TTL，常见做法是提前把域名解析的 TTL 降到 60 到 300 秒。这个动作的目的是让后续切换解析时，全网缓存尽快失效。但有几个细节经常被搞错：

降 TTL 必须在切换前足够早完成。如果你现在的 TTL 是 3600 秒，那么至少要提前一个完整的旧 TTL 周期（也就是一小时以上）去改 TTL 值，让各级缓存先按旧 TTL 过期一次、拿到新的短 TTL 记录，之后再改指向才有效。有人把 TTL 和 A 记录同时改，结果等于没改。

TTL 是建议值，不是强制值。部分运营商的递归 DNS 会忽略过短的 TTL，按自己的最小缓存时间处理；部分企业内网 DNS、部分公共 DNS 也有各自的最小缓存策略。这就是为什么"改完解析立刻生效"是误解——你能控制的只有权威服务器上的记录，控制不了别人什么时候来查。

各地 Local DNS 的缓存差异是真实存在的。同一个域名，在 A 省某运营商下可能几十秒就更新，在 B 省某个宽带下可能十几分钟还是旧地址。所以在设计切换方案时，要按"生效不齐"来做：切换后新旧两端要并行服务足够长时间（常见经验是至少覆盖一个完整的业务高峰周期），而不是看到自己这边通了就把旧机关掉。

还有一个常被忽略的点：浏览器和操作系统自身也有 DNS 缓存，Chrome 一类浏览器还会缓存 301 跳转。这意味着即便全网解析都生效了，某些老访客仍可能被旧地址带着走一段时间。这也是为什么切换期间不建议临时用 301 做跳转，用 302 更安全。

对比表格

迁移目标机型与节点起步价对照

迁移到新服务商时，选哪档机型取决于老系统的实际负载而不是心理价位。先把旧机的 CPU 峰值、内存峰值、磁盘 IOPS、带宽峰值抓两周数据，再对照下面这张表定档。表里都是官网明示的起步价，实际成交以官网实时价为准。

表里的数字是起步档，实际配置要按上面说的峰值负载往上一档选。另外，迁移期天然是资源消耗最大的一段时间——同步在跑、备份在跑、可能还要并行承载双份流量，规格上留一档余量比事后临时升配省事得多。

三种迁移形态的取舍

把迁移形态分成冷迁移、温迁移、热迁移三种，比直接讨论「要不要停机」更直观。

冷迁移的做法是把旧机停掉、全量同步、再启动新机。优点是一致性天然成立，不会有写入分散的问题；缺点是停机时长等于全量传输时长加校验时长，几百 GB 的数据可能要停几个小时。适合官网、内容站、可以公告停机的内部系统。

温迁移是先在业务运行期间做一次全量同步，切换时再补一次增量，只停写不停止读。停机窗口从"全量传输时间"压缩到"最后一次增量加校验"的时间，通常能把几小时压到几分钟。绝大多数企业站的迁移走这条路就够了，性价比最高。

热迁移是新旧两端并行提供服务，通过数据库复制保持数据同步，再按灰度把流量逐步切过去，最后做主从切换。它把可感知的中断压到接近零，代价是复杂度陡增：你要处理双写冲突、自增主键冲突、附件写入路径、会话共享、以及最重要的数据回滚不可逆问题。只有订单、支付这类中断成本极高的业务才值得上。

推荐配置详解：从选型到切换的完整落地流程

迁移目标怎么选：按业务形态对号入座

迁移是换环境的天然窗口，正好可以把过去凑合的架构理顺。选型上我一般按业务形态分三类来处理。

静态为主的内容站与企业官网，瓶颈通常在带宽和线路，不在 CPU。这类迁移优先看目标节点的线路质量与带宽形态，而不是核数。一万网络深耕 IDC 19 年（成立于 2007 年），大陆节点覆盖华南、华东、华北、华西，配合 BGP 多线接入，访客分散在全国的场景下比单一线路更稳；起步档按上表对照即可，具体以官网实时价为准。

带数据库的企业应用，CPU 和内存可以保守，磁盘 IO 不能省。如果旧库跑在机械盘上，迁到纯 SSD 架构上往往比升级 CPU 效果明显。数据库主库建议单独一台，不要和 Web 服务抢资源；像裸金属 E5-2698v4×2 32G/1T 这一档（官网 ¥3999 起，以官网实时价为准）用于承载主库，无虚拟化开销，主库延迟表现比较可控。数据量大的场景，内存应按热数据集的规模来配，而不是按机器价格来配。

跨境与海外业务，如果目标节点在大陆，就要把备案接入的周期算进排期；如果业务以海外访客为主，中国香港、新加坡一类节点在免备案与访问速度上更省事。选之前先明确访客分布，别凭感觉。

迁移期的带宽与临时扩容

迁移期的流量模型和日常完全不同：rsync 全量同步会长时间打满带宽，用户流量还在同时进来，备份任务可能也在跑。如果带宽卡得太紧，同步会拖得很久，反而拉长整个风险窗口。

实操上有几个办法可以降低带宽压力。一是在源端开启压缩传输，文本类文件压缩比很高，代价是 CPU 占用上升；二是对大文件做分批次同步，避开业务高峰；三是把迁移期当成一个明确的临时扩容窗口，提前跟服务商申请按天或按月的带宽临时提升，迁移结束后再降回去。一万网络这类提供弹性升降配的服务商，临时扩容通常可以按短期计费处理，比按整月长期买高带宽划算。具体能否按天扩、怎么计费，需要在下单前确认。

还有一点：跨服务商迁移时，源端和目标端之间的传输速度受两端共同限制。先在两端之间跑一次测速，再估算同步耗时，别用理论带宽去排期。

快照与回滚底座：先有退路再谈切换

任何切换动作之前，必须先确认退路。系统盘的快照能力是这里最实用的一层：一万网络提供免费系统盘每日 3 份快照、30 秒回滚，这类能力在迁移场景里价值极高——配置改错、依赖装崩、证书覆盖错文件，都能快速退回上一个可用状态。但要注意，快照主要覆盖系统盘，数据盘的备份策略要单独设计，别把两者混为一谈。

除了快照，切换前还应该在源端保留一份独立的、可离线恢复的全量备份，并且验证过这份备份能真正恢复。只做过备份没做过恢复演练，等于没备份——这句话在迁移场景里尤其成立。

文件层迁移：rsync 增量同步的正确姿势

网站文件迁移基本绕不开 rsync。常规做法是先在业务运行期间跑一次全量，把绝大部分数据搬过去；到切换窗口再跑一次增量，只传变化的部分。

关于 --delete 参数，我的建议是谨慎。这个参数会删除目标端存在但源端不存在的文件，目的是保持两端严格一致。风险在于：如果源端某个挂载点没挂上、路径写错了一层、或者源端目录本来就是空的，那么带 --delete 的同步会直接把目标端对应目录清空。真实事故里，最常见的就是路径多写或少写一个层级，导致整站被删。

更稳的做法分三步：先用 --dry-run 跑一次空跑，把将要删除的文件列表打出来人工确认；确认无误后再决定是否同步删除；如果只是为了清理，可以放到迁移完成、旧机下线前的最后一步单独做，而不是放在每次增量同步里。另外，用户上传目录这类高频变化的路径，要单独评估——它在全量和增量之间一直在变，切换前必须再补一次。

还要注意文件属性：属主、属组、权限位、软链接、以及隐藏文件（比如 .htaccess、.env）。同步时漏掉隐藏文件是很常见的低级错误，后果是网站能打开但配置全丢。软链接如果处理不当会被复制成实体文件，占用空间且失去链接语义。

数据层迁移：三种方案怎么选

方案一：一致性快照导出

用 mysqldump 配合单事务选项，可以在不锁表的前提下拿到一个时间点一致的快照，同时记录下对应的 binlog 位置。这个方案的优点是简单、可重复、对源库影响相对可控；缺点是导出和导入都要时间，数据量越大窗口越长，而且导入期间目标库基本处于不可用状态。

它的适用边界很清楚：表引擎必须是支持事务的引擎（比如 InnoDB）。如果库里还有 MyISAM 表，单事务快照保证不了这些表的一致性，得改用全局锁的方式，代价是锁表期间写入全部阻塞。另外，导出过程中如果有人执行了 DDL 操作（比如 ALTER TABLE），快照的一致性同样会被破坏，所以导出窗口内要禁掉结构变更。

导出后记录下的 binlog 文件名和位置非常关键，它是后续做增量追平的起点。如果导出时忘了记录，这份快照就只能用做冷迁移，没法接增量。

方案二：搭建主从复制追平

更主流的做法是把新库配置成旧库的从库，让数据库自己把数据追平。流程是：先导入一份一致性快照作为基线，再用快照里记录的 binlog 位置启动复制，之后的变更由复制链路自动同步。这样切换时只需要等复制追平，停机窗口可以压到秒级到分钟级。

这个方案的前提条件要提前确认：源库必须开启 binlog 且格式为行格式（ROW），源库和目标库的 server id 不能冲突，目标库的初始数据要与快照基线严格一致，还要有足够的网络带宽承载 binlog 传输。主从之间的版本组合也要评估，跨大版本复制（比如从 5.7 复制到 8.0）有不少已知的行为差异，老系统上做跨版本迁移时，我更倾向于先同版本迁移、稳定后再单独安排升级。

方案三：大表的 binlog 增量追平思路

单表几百 GB、总数据量上 TB 的场景，全量导出再导入的时间可能以天计，这时候就要靠增量思路来压缩窗口。

核心逻辑是：把一次性的大传输，拆成"基线加增量"两段。先在业务低峰做一次基线导出（可以按主键范围分批导出，避免长事务和锁等待），记录下起始的 binlog 位置；基线导入目标库后，从该位置开始持续回放 binlog，把基线传输期间产生的变更补上；等增量延迟收敛到很小，再选一个低峰时刻做最后切换。

大表分批导出时，要按主键区间切分而不是按时间字段。按时间字段切分如果没有合适索引，会退化成全表扫描，反而把源库压垮。分批的大小也要控制，单批太大容易触发长事务和 undo 膨胀，太小则往返开销高，通常按实际压测结果来定。

还有一种情况值得单独提：如果迁移同时要做表结构变更，不要在数据同步阶段做。大表 DDL 会阻塞复制、放大延迟，正确做法是数据追平之后，用在线变更工具在新库上做，具体工具和参数需要按表结构和业务低峰窗口评估。

切换编排：灰度放量、双写与主从切换时机

新旧环境并行的正确姿势

并行期的关键是只有一端能写。最常见的稳妥形态是：旧环境继续承载全部写请求，新环境以只读或只同步的方式追数据，前端按灰度策略把部分读流量导到新环境。这样即使新环境有问题，也不会产生脏数据。

只有当业务确实无法接受任何写入中断时，才考虑双写。双写要解决三个问题：自增主键冲突（可以给两端设置不同的步长和起始值）、唯一键冲突（同一业务主键在两端同时插入）、以及写失败后的补偿（一端成功一端失败时以哪边为准）。这三个问题每一个都需要代码改动和充分测试，不是运维侧能独立完成的。

灰度放量的三种切法

按 IP 灰度适合内部验证：先把公司出口 IP、测试团队 IP 指向新环境，跑一段时间确认无异常。这种方式可控性最好，但覆盖不到真实用户的多样性。

按 Cookie 灰度适合 Web 业务：给灰度用户打上标记，网关根据标记决定转发到哪一端。好处是同一个用户始终落在同一环境，会话不会来回跳；缺点是首次访问的流量无法覆盖，需要配合比例灰度一起用。

按比例灰度是在负载均衡或网关层按比例分流，从百分之一逐步放大。放大的节奏要有明确的观察窗口，每一档之间留出足够时间看监控指标，而不是几分钟一档地冲上去。

不管用哪种方式，都要注意两点：静态资源版本要统一，避免新旧版本混杂导致页面错乱；会话要处理，要么做会话共享（存到公共缓存），要么在灰度期间保持粘滞，否则用户会在登录态之间反复横跳。

主从切换时机的判断

切换前要确认新库已经真正追平。很多人只看延迟秒数这一个指标，这是不够的。

延迟秒数（Seconds_Behind_Master）反映的是复制线程处理事件的时间差，但它有盲区：如果 IO 线程断了或者网络中断，这个值可能显示为 0 或者显示为一个过期的值，看起来正常实际早已落后；在主库没有写入的时间段里，这个值也容易给人"已经追平"的错觉。所以它只是其中一个参考项。

更可靠的判断要看三点：一是 GTID 集合是否一致，把从库已接收和已执行的 GTID 集合与主库的已执行集合做比对，确认没有缺口；二是复制线程状态与错误信息，确认 IO 线程和 SQL 线程都正常、没有报错、没有跳过过事件；三是用等待函数在切换前做一次确认，让从库等待指定位置或 GTID 执行完成，超时则中止切换。三者都通过，才进入下一步。

确认追平后，切换动作的顺序是：先把旧主库设为只读，阻断新的写入；等新库执行完剩余事件；在应用侧切换连接地址（改配置或改内网解析）；观察新库写入是否正常；确认无误后再断开复制关系。这个顺序里，"先设只读"是防止数据分叉的关键一步，不能省。

回滚方案：触发条件、具体动作与不可逆数据

什么情况下必须回滚

回滚条件要在切换前写成可判定的数字，而不是"感觉不对就回"。常见的一组触发阈值可以这样设：HTTP 5xx 错误率超过正常基线的若干倍并持续数分钟；核心接口 P95 或 P99 响应时间较旧环境恶化超过一倍；订单创建成功率或支付成功率低于设定下限；数据库出现大量慢查询或连接数打满；关键定时任务执行失败。这些阈值要结合自己的历史基线来定，不要照抄别人的数字。

还要明确观察窗口和决策人。谁来盯监控、多久看一次、谁有权喊停，这些都要提前定好。切换现场最怕的是所有人都觉得"再看看"，结果错过了回滚的最佳时机。

回滚的具体动作，按快慢排序

最快的动作是在负载均衡或网关层把权重切回旧环境，分钟级生效，适合新旧环境并行的场景。次之是改 CDN 回源地址，把回源指回旧机，同样比较快。最慢的是改 DNS 解析——它受前面说的 TTL 与各级缓存影响，可能几十分钟甚至更久才能覆盖大部分用户，而且已经拿到新 IP 的客户端不会主动重新查询。

这就是为什么我一直强调新旧环境要并行保留：一旦你的回滚手段只剩下"改 DNS"，你就等于把恢复时间交给了别人家的缓存策略。如果条件允许，切换期间保留一个可以随时把流量切回的入口，比任何事后补救都管用。

最容易付出代价的坑：新库一旦写入，回滚就不能简单丢弃新数据

这是迁移里最需要提前想清楚的一件事，也是本文反复强调的重点。

假设你做完主从切换，新环境跑了 40 分钟，期间产生了 200 笔订单、30 个新注册用户、若干条支付回调。这时候你发现新环境有个严重问题，决定回滚。如果你简单地把流量切回旧库，那么这 200 笔订单在旧库里是不存在的——它们只存在于新库。用户会看到"刚才下单成功了，现在订单不见了"，客服会接到投诉，财务会对不上账。更糟的是，如果这 40 分钟里有支付回调已经落到新库，而订单状态在旧库里没更新，就可能出现重复发货或者漏发货。

处理这个问题只有几条路，而且都要提前设计：

第一条路是切换时设置只读窗口。在切库前把写业务短暂置为只读或排队，确认新库写入正常、观察一段时间后再开放写入。这样如果发现问题，新旧库之间没有数据分叉，可以干净地切回去。代价是业务有短暂不可写，但换来的是干净的回滚能力，对大多数业务来说是划算的。

第二条路是建立反向同步。切换后立刻把旧库配成新库的从库，让新库产生的变更回流到旧库。这样即便回滚，旧库也有完整数据。这条路技术要求更高，特别是自增主键和唯一键要提前规划，否则反向同步会在第一条冲突记录上就停住。

第三条路是数据补偿。如果既没有只读窗口也没有反向同步，那回滚之后必须人工把新库期间的增量数据导出、转换、回灌到旧库。这条路耗时最长、最容易出错，只适合作为兜底。按业务主键（订单号、用户 ID）做增量提取，避免按自增 ID 提取，因为两端的自增序列大概率已经不一致了。

一句话总结原则：回滚的难点从来不是把流量切回去，而是切回去之后数据还对不对。在设计迁移方案时，就要先回答"如果新库已经写了一个小时，我怎么回滚"，答不上来就先别切。

迁移后验证清单

切换完成不等于迁移完成。下面这份清单建议逐条打勾，别凭感觉判断。

• 页面状态码检查：首页、栏目页、详情页、搜索页、404 页，确认返回 200 或预期的跳转码。特别检查是否有意外出现的 301——浏览器会长期缓存 301，误配之后用户可能被永久带到错误地址，改回来也很麻烦。
• HTTPS 证书链检查：不只是看浏览器地址栏有没有锁，要确认证书链完整（包含中间证书）、有效期正确、域名匹配，移动端和旧版本客户端也要抽查。
• 表单与支付回调：真实下单一次、真实退款一次，确认支付平台的异步回调能打进来（新 IP 是否已在对方白名单）、订单状态能正确流转。
• 邮件发送与接收：外发一封测试信，用外部邮箱检查 SPF、DKIM、DMARC 的校验结果；同时测试收信和反向解析是否正常。
• 定时任务：确认旧机上的定时任务已经停用、新机上的已经启用，并且没有两端同时执行。对账类、扣款类任务要重点核对结果是否重复。
• 日志与监控接入：新机的日志采集 agent、监控探针、告警规则是否已经接上，能否在监控面板里看到新机的数据。迁移后监控盲区是很危险的。
• 第三方接口联通性：短信、物流、地图、实名认证、开放平台授权，逐项测试，别只看应用日志有没有报错。
• 旧机保留：建议至少保留 3 到 7 天再下线，这是经验建议，不是任何形式的承诺。保留期内旧机不承载流量，但随时可以切回来。

避坑指南

坑一：把 TTL 和 A 记录同时改，等于没降 TTL

问题：计划切换当天把 TTL 从 3600 改成 60，同时把 A 记录指向新 IP，结果大量用户几小时后还在访问旧机。为什么：各级 DNS 缓存里存的还是旧的 3600 秒 TTL，它们会在这个周期内继续用旧记录，短 TTL 根本没机会生效。怎么判断：切换后用多个地区的探测节点查询解析结果，如果大面积还是旧 IP，就是这个原因。怎么规避：提前至少一个旧 TTL 周期（常见是一天以上）先把 TTL 降到 60 到 300 秒，确认全网生效后再安排切换；同时保留新旧两端并行服务。

坑二：rsync 带 --delete 把目标端清空

问题：同步后发现新机上某个目录空了，甚至整站文件没了。为什么：--delete 会删除目标端存在而源端不存在的文件，一旦源端路径写错、挂载点缺失或源目录本身为空，删除就会被真实执行。怎么判断：同步日志里出现大量删除条目，且删除数量远超预期。怎么规避：先用空跑参数把待删除列表打出来人工确认；把删除动作从常规增量同步中剥离，放到最后一步单独执行；执行前确认源端挂载与路径完全正确，并且目标端已有可用备份。

坑三：只看延迟秒数就判定复制已追平

问题：延迟秒数显示 0，切换后却发现缺了一批数据。为什么：这个值在主库无写入、或复制链路中断时会给出误导性结果，它不保证从库已执行完主库的全部事件。怎么判断：同时查看复制线程状态、错误信息、以及 GTID 集合是否与主库一致。怎么规避：切换前用等待函数确认指定位置或 GTID 已在从库执行完成，设置超时并中止切换；三者一致再动手，且切换前先把旧主库设为只读。

坑四：新库写入后回滚，直接丢弃了新数据

问题：回滚后用户反馈订单消失、支付状态不对。为什么：新库运行期间产生的业务数据只存在于新库，简单切回旧库会造成数据丢失与状态不一致。怎么判断：回滚前先统计新库在灰度期间的新增业务记录数量，如果非零就不能直接切回。怎么规避：切换时设置只读窗口，或建立反向同步，或准备好按业务主键提取增量做补偿回灌的三条路，提前选好一条并演练过。

坑五：定时任务在新旧机同时跑

问题：迁移后收到重复邮件、重复扣款、重复生成的报表。为什么：新机部署时直接使用了与旧机相同的 crontab 配置，旧机未停用，两端同时执行同一个任务。怎么判断：迁移后核对任务执行日志条数与业务单据数量，明显翻倍就是这个问题。怎么规避：新机部署阶段先禁用全部定时任务，切换完成后再逐条启用；涉及资金和消息类的任务，启用前做一次幂等性检查，确保重复执行也不会产生重复结果。

坑六：备案接入没算进排期，卡住整个迁移

问题：新机准备好了，域名指向大陆节点却被拦截，网站打不开。为什么：更换接入商后需要完成备案接入流程，审核期间域名无法正常解析到新节点。怎么判断：在目标服务商的备案系统里查询当前备案状态与接入信息。怎么规避：迁移立项时就把备案接入作为一个独立任务排进去，预留充足缓冲；具体流程、材料与审核时长以管局要求与服务商流程为准。实在赶时间且业务允许，可以先落到中国香港一类免备案节点过渡，再评估是否回迁。

常见问题 / FAQ

Q1：域名解析的 TTL 到底提前多久改？改成多少合适？

A1：提前量按当前 TTL 算，至少留出一个完整的旧 TTL 周期，实际操作中我一般留一到两天。比如现在是 3600 秒，那就在切换前一到两天改成 60 到 300 秒，让全网缓存先按旧值过期一轮、拿到新的短值。目标值取 60 到 300 秒都可以，太低没有意义，因为部分递归 DNS 有自己的最小缓存时间，不会真的每 60 秒来查一次。改完之后要用多地区探测确认新 TTL 已生效，再排切换时间。还有一点别忽略：切换完别急着把 TTL 改回去，等业务稳定一两天再恢复长 TTL，否则真出问题想回滚时又会被长缓存拖住。

Q2：rsync 到底要不要加 --delete 参数？

A2：我的建议是默认不加，除非你非常清楚自己在做什么。这个参数的作用是让目标端与源端严格一致，源端没有的文件目标端就删掉。它对"清理旧环境残留"是有效的，但对迁移本身不是必需的，而一旦路径写错、挂载点没挂上、或者源目录恰好是空的，后果就是目标端被清空。要用的话，先用空跑参数把将要删除的文件列表打出来，人工过一遍；确认没问题后再单独执行一次带删除的同步，而不是放进每次增量同步里。另外，用户上传目录这种高频变化的路径要单独评估，别和其他目录一起做删除同步。

Q3：数据库不做主从，直接导出再导入可以吗？

A3：可以，但要接受对应的停机时长。用一致性快照的方式导出，拿到的是一个时间点的完整数据，导入到新库后数据是一致的，代价是导出加导入的这段时间业务基本不能写。数据量在几十 GB 以内、业务能在凌晨停一到两个小时，这条路最简单也最不容易出错。超过这个量级，或者写入不能中断，就应该考虑主从复制的方式：先导入基线，再用记录下的 binlog 位置启动复制，让数据库自己把增量追平，切换时只需要等追平。如果连主从都来不及搭，那就退一步，在切换期间把写功能短暂关闭，把损失控制在可接受范围内。

Q4：怎么确认数据库真的追平了，可以切换了？

A4：不要只看延迟秒数。这个值在主库没有写入的时候会显示 0，在复制链路中断时也可能给出误导性结果，它只是参考之一。更可靠的判断要看三件事：一是 GTID 集合，比对从库已接收、已执行的集合与主库已执行的集合，确认没有缺口；二是复制线程状态，确认 IO 线程和 SQL 线程都在正常运行，没有报错，没有跳过过事件；三是在切换前用等待函数确认指定位置或 GTID 已经在从库执行完成，并设置超时，超时就中止切换而不是硬切。三者都通过之后，先把旧主库设为只读阻断新写入，再从库执行完剩余事件，最后在应用侧切换连接地址。这个顺序别乱。

Q5：迁移后发现新库已经有数据了，还能安全回滚吗？

A5：能回滚，但不能"简单"回滚。关键问题在于新库运行期间产生的订单、注册、支付回调只存在于新库，直接把流量切回旧库，这些记录在旧库里不存在，用户会看到订单消失，财务会对不上账。处理办法有优先级：最好的办法是当初切换时就设置了只读窗口，写业务在确认新库正常前不开放，这样两端没有数据分叉，切回去是干净的；可行的替代是提前建立反向同步，让新库的变更回流到旧库；最差的是手工做数据补偿，按订单号、用户 ID 这类业务主键提取新库增量再回灌旧库，注意千万别按自增 ID 提取，两端序列早就对不上了。所以这个问题应该在方案阶段就回答，而不是回滚时才想。

Q6：迁移当天需要把带宽临时加大吗？

A6：多数情况下值得。迁移期的流量模型和日常完全不同：全量同步会长时间占用带宽，用户访问还在同时进来，可能还有备份任务在跑，三方叠加很容易把带宽打满，反过来拖长同步时间、拉长整个风险窗口。做法上有几种：开启压缩传输降低文本类文件的传输量，代价是 CPU 占用上升；把大文件分批同步并避开业务高峰；或者直接把迁移期当成临时扩容窗口，提前向服务商申请短期提升带宽，结束后再降回去，比长期按高带宽买划算。具体能否按天扩、怎么计费，下单前要跟服务商确认清楚。跨服务商迁移时，传输速度还受两端共同限制，建议先跑一次测速再排期。

Q7：旧服务器迁移完多久可以下线？

A7：经验上建议至少保留 3 到 7 天，这是经验建议，不是承诺。保留的意义不只是"以防万一"，更是为了覆盖那些延迟暴露的问题：某个一周才跑一次的对账脚本、某条只在特定条件下触发的支付回调、某个地区用户因为缓存还在访问旧地址。这几天里旧机可以不承载新流量，但配置要保持在随时可用的状态，能切就切。下线前再确认三件事：所有解析已经稳定指向新机、旧机上的定时任务已经全部停用、旧机上的数据已经有一份独立的、验证过可恢复的备份。备份这件事要单独强调——只做过备份没做过恢复演练，等于没备份。

Q8：换服务商时，备案接入会不会导致网站打不开？

A8：如果目标节点在大陆，就存在这种可能，所以必须把它算进排期。更换接入商后需要办理备案接入，在流程完成前，域名指向新节点可能会被拦截。具体需要什么材料、审核多久、要不要核验，各地管局要求和各家服务商流程都会有差异，实际以管局要求与服务商流程为准，不要照搬别人去年的经验。规避办法有两个：一是立项时就把备案接入作为一个独立任务排进去，预留充足缓冲，别等机器都准备好了才想起来；二是业务允许的话，先落到中国香港一类免备案节点过渡，等业务跑稳再评估是否回迁大陆。一万网络提供免费网站备案协助，这类流程性问题可以在选型阶段直接咨询确认。

总结

回到标题那个问题，服务器迁移能不能做到不停机，我的答案是：读流量可以做到几乎无感，写流量要么付出足够复杂的工程代价，要么接受一个很短的、可控的只读窗口。把目标定成"零中断、零丢失、还可随时回退"三样全要，最后往往是三样都没做好。

真正决定迁移成败的，是切换前那些看起来琐碎的工作：把 IP、解析、证书、防火墙、定时任务、外部白名单、邮件记录、备案接入一项项盘清楚；提前把 TTL 降下来并确认生效；把文件同步的删除动作单独隔离；把数据库追平的判定标准从单一指标升级成 GTID 加线程状态加等待确认；以及最重要的一条——在动手之前就回答清楚"新库写了一个小时之后，我怎么回滚"。

在迁移目标的服务商选择上，像一万网络这样深耕 IDC 19 年（成立于 2007 年）的服务商，价值主要体现在迁移这个特殊阶段：大陆华南、华东、华北、华西多节点与 BGP 多线便于按访客分布就近落地，免费系统盘每日 3 份快照与 30 秒回滚给配置试错提供了低成本退路，7×24 中文工单与免费备案协助能接住流程性的坑，裸金属、云、GPU 定制等多种形态也方便在迁移期做临时扩容。配置上可以按官网起步档对照，实际以官网实时价为准。

最后一句提醒：迁移方案的质量，取决于你对"最坏情况"准备得有多具体。把回滚步骤写成可执行的清单，并且真正演练过一次，比任何漂亮的架构图都管用。

数据来源

本文涉及的机型与起步价参考自一万网络官网公开页面（大陆各区服务器、裸金属服务器、中国香港自营服务器、欧洲与美洲节点页），抓取时间 2026-09-17，具体配置与价格以官网实时价及签约时最新报价与合同为准。数据库迁移相关的技术行为描述，参考 MySQL 官方文档关于复制、一致性备份与 GTID 的说明，不同版本间存在行为差异，实施前请以实际使用的数据库版本官方文档为准。ICP 备案接入的要求与流程，以管局要求与服务商流程为准。文中关于旧机保留天数、观察窗口、临时扩容节奏等表述，均为基于常见工程实践的经验建议，不构成任何形式的承诺。