网站换服务器要停机多久

换机器这件事，最怕的不是搬不动数据，而是搬的过程中业务停了、域名切过去还不生效、想切回来又回不去。有人凌晨动手天亮还在修，有人以为十分钟能完事，结果卡在数据库同步上。停机时间到底花在哪几步、哪几步能提前做完、什么情况下必须留回滚方案，这篇按实际排期的顺序讲。

停机时间花在哪一步

把整件事拆开看是四段：准备、数据同步、切换、验证。真正需要停业务的只有\"停写到切换完成\"这一小段，前面的环境搭建和第一轮全量同步全都能在旧机器照常服务的情况下做完，很多人把全量同步也算进停机窗口，结果被迫停一整天。按这个分法排期，真正的停机窗口往往能压到半小时以内，剩下的时间都是给意外留的余量，留少了就只能现场改方案，而现场改方案最容易漏步骤，漏的那一步通常在数据一致性上，而这类问题往往几天后才浮现，排查成本最高。

准备阶段的工作量常被低估。目标机器要装同一版本的程序、同样的扩展、同样的时区与字符集，还要把定时任务、日志轮转、证书、防火墙规则逐条照搬。这些在旧机器跑得好好的东西，换一台机器就会暴露出各种隐式依赖，早一点装好就能早一点发现问题，把这些逐项写成清单打勾，比靠记忆可靠得多。

切换那几分钟里要做的事其实很少：停写入、确认增量数据追平、切解析、观察第一批请求。之所以显得紧张，是因为前面没准备好，等切过去才发现某个扩展没装、某个密钥没配，业务就停在那儿等人修。到头来决定停机长短的，是准备阶段做得多细，而不是切换那一刻手速多快。清单越细，切换那半小时越不慌，提前把命令准备好，复制粘贴比现场敲要稳。

数据怎么同步过去

文件用增量同步工具跑两轮。第一轮全量，在线做，旧机器照常对外服务；第二轮只同步变化的部分，放在切换前跑，几千万个小文件也能在十几分钟内追平，前提是第一次全量已经把主要体积搬完。别用压缩打包再解压的方式搬大目录，解压一次的时间够增量跑十遍。

数据库不要直接拷数据文件。老老实实导出导入，或者搭一套主从让增量自动追平。数据量大的库，主从方式最省事，切之前确认从库延迟接近零，再停止写入，切换几乎感知不到，延迟追到零附近再动手，这个判断比任何口头承诺都准。

缓存和会话别带过去。旧机器上的缓存键、会话文件、临时目录一并清空重建，带过去只会让新机器读到指向旧环境的数据，出现登录失效、页面串数据这类难查的问题。切完让缓存自然预热，第一批请求慢一点属于正常，几分钟后就会回到常态。

同步完必须校验。文件数量和总字节数对一遍，数据库逐表对比行数，关键业务表抽样比对几条记录的内容。数字对不上就停在准备阶段继续追，别带着不确定切换，切完再发现少了几千条订单就麻烦了。

同步过程中把速率记下来。一小时能搬多少 G、数据库追平要多久，用这些实测数字反推停机窗口该留多长。凭感觉估出来的半小时，经常在执行时变成三小时，问题不在数据量，在于从来没量过。量一次，下一次就有底了。

域名和 DNS 怎么切

先切测试域名。用一个不影响线上的二级域名指向新机器，把注册、登录、下单、支付回调、后台管理逐条走一遍，这些都通了再动主域名。测试域名走通的流程，切主域名时基本不会翻车。测试域名最好用完全相同的配置，别为了图快跳过后台和回调，这两条路径的问题留到主域名切换后才暴露，代价最大。测试域名这一轮别省，省下的时间会在故障时成倍还回去。

提前一天把解析的 TTL 调小。三十分钟甚至五分钟，让切换之后能快速生效。TTL 还挂着一整天的时候去切解析，等于给自己埋了一颗要等二十四小时的雷，出问题想回滚也得等同样长的时间。提前一天动手改，成本几乎为零。

如果前面挂了内容分发网络，切换顺序要注意：先把回源地址指向新机器，再刷新缓存，末尾切解析。顺序反了会出现旧缓存继续吐旧内容、新机器却拿不到请求的情况，两边数据不一致，排查起来很费劲。顺序记在流程文档里，别靠现场回忆，切错的代价是多等一轮缓存过期，而缓存过期的时间是按分钟算的，越急越容易在顺序上犯错，所以顺序要提前固化。

切完之后让新旧机器并行服务一段时间。旧机器先不关，日志继续收集，把两边的错误率和响应时间放一起看，确认新机器稳定再下线旧入口。这段并行期是免费的保险，多留一天不心疼。

回滚预案怎么留

回滚的前提是旧机器先别关。至少保留二十四到四十八小时，磁盘别急着释放，账号别急着退。见过切换当晚就释放旧机器的，第二天发现新机器有兼容问题，只能从备份里一点点往回捞。

切换前把旧库设成只读或停写，记下切换点的准确时间。回滚时按这个时间点找回数据，比凭记忆判断\"大概是十点半左右\"可靠得多。时间戳写进执行清单，别只留在脑子里。

域名回滚比正向切换更慢。缓存已经在用户侧和中间节点上，改回去也要等一轮 TTL。所以回滚决策要早，宁可误判一次白回滚，也不要犹豫两小时让损失扩大。

写一份回滚步骤清单：谁执行、按什么顺序、每步验证什么、失败之后怎么办。清单提前写好打印出来，故障时照着念就行，不需要临场回忆。人在紧张状态下会漏步骤，这是常识不是能力问题。

数据回滚最麻烦。新机器上跑了几个小时，已经产生新订单、新注册、新内容，这些数据要么反向同步回旧机器，要么至少完整导出保留。回滚方案里必须单独写这一条，否则回滚之后用户会发现自己的操作没了。

设定明确的回滚触发条件。错误率超过百分之几、支付失败率超过多少、核心接口超时比例到什么程度，达到就回滚，不讨论。有量化门槛，值班的人不用背责任，执行速度也快得多。

回滚也要演练。哪怕只在测试环境走一遍，把清单从头到尾执行一次，看看哪一步会卡住、哪个命令写错了、谁没有权限。演练花两小时，真出事时能省掉一整夜。

迁移后的观察期

前二十四小时盯四样东西：错误日志、慢查询、响应时间、带宽曲线。和迁移前同一时段的基线比，差异明显就去查原因。新机器没有历史包袱，指标通常会更好看，如果反而变差，几乎一定是配置没搬全。

观察搜索来源和收录变化。换机器不影响域名，理论上不该有波动，但解析过程中的短暂不可用、证书配置错误都会影响抓取。发现抓取异常就去检查证书、robots、状态码，别等到排名掉了才动手。抓取日志在服务端也留一份，两边对得上才说明没问题，对不上先查是不是回源到了旧机器。

旧机器保留但关闭对外入口，只留一份数据快照。用户从旧链接进来的情况要挡住，可以用解析层面处理，也可以在旧机器上做一个跳转，避免出现两个入口各自更新、数据越走越远。跳转规则写清楚，三天后撤掉，久了会变成没人认领的配置。

一周之后做收尾。确认新机器稳定、备份正常、监控覆盖到位，再清理旧机器上的临时文件、下线临时解析记录、退还不再需要的资源。收尾不做，这些东西会在半年后变成没人敢删的历史遗留，收尾这一步别拖，拖过一周基本就没人愿意回头整理了。

把这次迁移的实际耗时、踩到的坑写进文档。下次再换机器，直接照着改，不用从头摸一遍。经验只有落成文字才有复用价值，留在个人记忆里等于没有，写下来还能给下一个人省一整晚。

大容量机型在迁移里怎么用

迁移期最缺的是能放下全量副本的空间。六 T 机械盘那一档（八千元级别里 6248 单路、一百二十八 G 内存、六 T SAS、两 G 端口配四十 T 月流量）适合当临时中转和落地备份，全量数据先落到它上面，再从它往新机器推，旧机器就不用一直扛着双重压力。大容量香港独服在这个位置比固态机型更合适，机械盘的顺序写性能足够，容量单价低得多。

一 T 固态那一档（七千五百元级别里同样是 6248 单路、六十四 G 内存、一 T 固态、两 G 端口四十 T 月流量）适合直接当新主机。数据库导入、程序编译、日志写入都吃随机读写，固态在这几件事上比机械盘快一个量级，切换后的第一波访问也扛得住。固态档的机型是主力位置，不建议拿它去当临时仓库。

冷热分开搬是个实用技巧。历史归档、图片原图、日志备份这类冷数据放机械盘，数据库、程序、最近三个月的内容放固态，搬的时候按冷热分两批走，等待时间能砍掉一半以上。

带宽直接决定搬运时长。两 G 端口理论上一晚能搬走几个 T，四十 T 的月额度也够一次大规模迁移用。端口小、额度紧的机型不是不能搬，只是要把窗口排到夜里，并且分批做，急不来。

迁移完成后把中转机改成备份机。数据已经在那儿放了一份，加个定时任务继续同步，它就从临时角色变成异地副本，钱没白花，也省了再买一份备份空间的支出。

预算上算一笔：多留一台机器一个月的钱，远低于停机一天的损失。迁移期间多一台机器不是浪费，是把风险摊薄，这笔账在排期会议上说得清，事后也不会有人觉得多花了。