网站迁移到新服务器如何不宕机：实操步骤与防坑指南

网站迁移到新服务器如何不宕机，核心在于将中断窗口压缩到用户无感知的程度。实现这一目标需要做好三件事：数据实时同步、流量可控切换、异常秒级回滚。以下是一套线上验证过的实操顺序。

先对环境，别急着传数据

目标机先把操作系统、Web服务器、运行时的版本跟原机对一遍，特别是php.ini里的内存限制、上传大小，Nginx的worker进程数这些，差一点点就可能导致切过去后页面报错。建议用同一份Ansible剧本或者至少手动diff一下配置文件。两台机子之间最好走内网专线或VPC对等连接，后面做rsync和数据库复制都稳定些。

文件同步：先全量，再增量

站点文件别等到迁移当天才传。先用rsync做一次全量同步，后面挂个定时任务做增量同步，参数带上 -avz --delete，保证两边完全一致。要特别注意用户上传目录的属主和权限，提前在目标机建好相同的用户组，保持UID和GID一致，否则切过去全是403。静态资源如果特别大，可以单独开一条同步任务，别跟代码文件混在一起。

数据库：提前搭好主从复制

MySQL或PostgreSQL最稳妥的做法是把新库配成从库，让数据实时追着跑。原库开binlog，导一份全量数据过去，记下binlog位置，然后新库执行CHANGE MASTER指回原库。平时就盯着Seconds_Behind_Master，接近0才算合格。Redis的话用slaveof或者AOF+RDB混合同步，别等到切换前才用导出导入，那downtime根本压不住。

Session和缓存别放在本地

如果应用默认把session写本地文件，切机瞬间所有用户会掉登录。提前改成Redis或Memcached共享存储，新服务器直接连同一个缓存实例。应用缓存也一样，本机文件缓存或内存缓存切机后会大量回源，最好提前切到集中式缓存，或者至少把缓存预热脚本准备好。

流量切换：能走负载均衡就别改DNS

有Nginx反向代理、HAProxy或者云厂商SLB的话，这是最稳的。把新服务器以低权重加入后端池，比如先给5%流量，盯着错误日志和响应时间。没问题再逐步上调，直到100%后把旧节点摘掉。整个过程用户无感知。

如果没有负载均衡，只能动DNS。提前一周把TTL降到300秒左右。切换时改A记录到新IP，但因为DNS缓存，总会有部分请求落在旧机。这时候让旧机做一层反向代理到新机，或者把旧机数据库设成只读指向新库，防止数据分裂。千万别两头都写，否则数据对不上就麻烦了。

切换那几分钟的操作顺序

正式切数据库的时候，按这个顺序来：先给原库设read_only或暂停应用写入口，确认从库完全追上后，停止复制并提升为主库，然后改应用配置指向新库，最后放开写。整个过程控制在秒级，用户顶多感受到一次页面刷新变慢。如果对写中断极度敏感，可以在应用层做短暂双写，但逻辑复杂，一般中小业务用上面的单主切换就够了。

验证和回滚预案

流量切过去后，立刻看HTTP状态码分布、错误日志和核心业务成功率。建议提前写个脚本，对比新旧环境关键页面的内容哈希或接口返回，确保跑出来的结果一致。如果发现异常，马上把流量切回旧机，数据库连接也指回原库。所以切换前务必给原库做一次额外备份，或者至少让原库保持只读状态一段时间，别急着释放。

收尾别急着删旧机

新环境至少稳定跑完一个完整业务周期，比如24到48小时，确认备份和监控任务都指向新机后，再关旧机。旧机的快照或镜像保留一周以上，万一要回溯数据还有退路。整套流程先在测试环境完整演练一遍，把命令和顺序写成checklist，正式迁移时对着打钩，能少踩很多坑。