新站跑起来了，看着挺正常，最难受的那种毛病往往要等一两周才冒头：用户说下单了，后台查不到；文章明明改过了，前台还是老版本；客服说我这看得到啊，你刷半天也刷不出来。网站搬迁最怕是旧数据没同步，怕的不是搬不过去，是搬完之后两边都还在写，谁也说不清哪一份才最新。
网站搬迁最怕是旧数据没同步，那到底怕在哪儿
搬迁这件事本身不难，难的是什么时候算搬完。不少人的理解是，运维把文件拷过去、数据库导一遍，任务就算结束。可一个还在正常运转的站是活的：有人注册、有人评论、有人下单，后台在改价，定时任务在生成缓存，爬虫在爬。你拷文件那半小时里产生的新数据在哪儿，多半还留在老服务器上。这就是没同步最典型的场景，不是全都没过来，是中间断了一截。
断掉的那一截，往往正好最要紧。文章晚几分钟没人管，订单晚一分钟客服就得挨骂。
哪些数据最容易被落下
说几个常漏的。用户上传的图片和附件，通常不在网站根目录，而是挂在别的目录或者对象存储里，光拷根目录那个文件夹当然漏。日志和统计的原始数据，很多人觉得不重要，可真出了事要回溯、要做前后对比，没了就抓瞎。队列和定时任务更是重灾区，Redis 里的队列、crontab 里的任务，迁移时不一起搬，消息就悬在半空，用户付了钱系统没反应，这种最难查。
还有几样零碎的：证书的自动续期配置、.env 里的密钥、发信用的 SMTP 参数、防火墙和伪静态规则。单看每一样都不大，少一个就能让站看着好了但跑不起来。
数据库同步，光导出导入是不够的
mysqldump 那套流程谁都熟，问题不在命令，在时机。第一次全量导入是对的，可在正式切流量之前，只要老库还在写，你就得有个增量追平的过程，不然导入那一刻之后产生的数据全丢。有条件的话把新服务器当从库挂上去，让它一直追，看延迟是不是归零，而不是看导出的 SQL 文件有没有跑完，这两件事完全不是一回事。
没条件做主从的，就用土办法：切换前把老站置为只读，发个维护公告，后台先把写入入口关掉，再导一次，这时候数据才是对齐的。听着麻烦，但比切过去之后两边数据互相打架强太多。至于具体的复制方式、延迟怎么看，各家数据库版本的文档写得最清楚，以官方页面说明为准。
文件同步，别只盯着目录大小
rsync 好用，但 -avz –delete 这个组合有人闭着眼睛就敲。–delete 的意思是目标端多出来的文件会被删掉，要是源目录指错了一级，或者同步的时候正好有人在传文件，这一下就删得干干净净。稳妥点的做法是先加 –dry-run 跑一遍，把清单看一遍，心里有数了再真同步。
另外别拿 du 出来的总大小对不上就慌。缓存文件、临时文件，还有那些被删了但进程没释放的句柄，都会让两边体积不一样。真要核对，比对文件数量、比对关键目录的清单，比看总大小靠谱得多。
切换顺序排错，前面做的全白费
顺序这事，踩过坑的都懂。大概是这样：先把新环境搭好、数据追平，本地用 hosts 绑一下做全链路测试，下单、支付回调、邮件、短信、上传一个都别跳过，确认没问题了再改 DNS。改完解析别急着把老服务器关机下线，让它再开一阵做兜底。
DNS 是有缓存的，不同地区生效时间还不一样，这段时间两边都得能访问，老 IP 也得回得了页面。有人图省事，改完解析直接关机，结果一部分用户还在往老 IP 上撞，直接白屏。想少点这种糟心事，把 TTL 提前调小是个简单办法，提前一天改，别等切换当天才想起来。
搬完当天和搬完一周，各核对什么
当天要看的：新站能不能正常发文章、传图、下单；后台的定时任务有没有真的在跑；队列里有没有积压；邮件短信能不能发出去；老 IP 上的站是不是还能打开。一天之后再看数据库的延迟有没有归零，有没有哪张表在疯长，日志里有没有连接超时的报错。
一周之后，才对得上那些慢性的问题。把老服务器的访问日志翻出来，看还有没有真实用户在访问，有的话说明解析还没完全收敛，或者有人写死了 IP。再看看用户反馈里有没有我提交了但没看到这一类的，这种反馈一出现，八成就是同步断口还留着。
与其纠结用哪套工具，不如先把一件小事做了：把这次搬迁里所有会写数据的地方列一张清单，数据库、上传目录、缓存、队列、定时任务、日志、证书、配置文件，挨个写上怎么搬、什么时候搬、搬完怎么验。清单写完你会发现，真正花时间的不是拷数据，是确认哪些数据还没被搬完。搬迁那天盯着新站能不能打开没什么用，愿意多花半天做增量追平和两边核对，后面能省下好几天的救火。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
