新加坡大带宽服务器迁移数据量大?如何快速同步?

前几年，我帮一家做东南亚电商代运营的公司做服务器迁移。他们的业务主要面向印尼和马来西亚市场，主服务器一直放在新加坡。那台机器配置不低，带宽也够用，跑了两年多一直挺稳的。

但问题出在去年——业务增长太快了，老机房的硬件扩容跟不上，他们决定换到另一家新加坡机房，配置更高、带宽更大。听起来很简单对吧?把数据打包、传过去、解压、完事。

可现实给了我一记响亮的耳光。

他们那台服务器上的数据，不算数据库光附件就有1.2个T。新加坡本地的内网速度自然不用愁，但源机房和目标机房之间走的还是公网链路。我算了算，按普通scp的传输速度，这1.2T得传将近三天三夜。

业务能停三天吗?显然不能。

那几天我试了好几种方案，走了不少弯路，最后才摸索出一套靠谱的流程。今天就把这些经验和教训分享给你，希望能帮你少踩几个坑。

一、先弄清楚：你面对的到底是什么样的“大量”

在聊具体方案之前，我觉得有必要先帮你自己判断一下，你的“数据量大”到底属于哪个级别。

不同的数据量，策略是完全不一样的。

如果你的数据在几十个GB以内，说实话，随便用什么方法都行。打个压缩包，用scp或者rsync传过去，睡一觉起来就好了。最原始的FTP也能对付。

但如果你面对的是几百GB甚至上TB的数据，像我那次一样，那普通方法就不够用了。你得考虑传输过程中断了怎么办、要不要压缩、要不要分片、要不要做增量。

而如果你的数据量达到了几个TB甚至几十TB，那已经不是“传”的问题了，你得考虑物理运输——直接把硬盘寄到机房。虽然听起来有点原始，但在某些极端场景下，这反而是最快的方式。

咱们今天主要聊的，就是中间这个“大几百GB到几个TB”的常见区间。这个体量说大不大说小不小，用对了方法能省下好几天的时间。

二、选对工具：rsync才是你的主力，别死磕scp

很多人一说到文件传输，第一个想到的就是scp。这玩意儿确实简单，一条命令就完事。但它的致命弱点是——断了就得重来，不支持断点续传。

你在传一个200GB的文件夹，传了百分之八十的时候网络闪断了一下，scp直接报错退出，下次再来得从头开始。这种体验，经历过的人都懂那种欲哭无泪的感觉。

所以我的第一条建议是：忘掉scp，把rsync作为你的主力工具。

rsync有个非常实用的特性叫“增量传输”。它不会傻乎乎地把整个文件再传一遍，而是会对比源文件和目标文件的差异，只传输变化的部分。这对于反复同步的场景来说简直是神器。

我给你一条我常用的命令格式，你可以根据自己的情况调整：

rsync -avzP --delete --bwlimit=50000 /data/ root@新服务器IP:/data/

我来拆解一下这几个参数的意义。 -a 是归档模式，保留文件属性和权限。 -v 是输出详细信息，让你能看到它在干嘛。 -z 是开启压缩，在传输前先压缩数据，可以节省带宽。 -P 这个参数比较关键，它包含了 --partial 和 --progress，支持断点续传并显示进度。 --delete 的意思是如果源端删了某个文件，目标端也跟着删，保持两边完全一致。 --bwlimit 是限速，单位是KB/s，避免迁移任务把带宽占满影响线上业务。

这条命令跑起来之后，你会看到清晰的进度条。万一中途断了，再执行一次同样的命令，它会从断点继续，不会重新来过。

三、数据库迁移：停机时间最短的方案

文件好办，数据库才是迁移中最让人头疼的部分。你不能直接把数据库目录拷走，因为迁移过程中用户还在写入，数据一直在变。

怎么做才能让停机时间最短?我的经验是分三步走。

第一步，先做一次全量备份，恢复到新服务器上。

对于MySQL，我习惯用mysqldump加上 --single-transaction 参数。这个参数能保证导出的是一个一致性快照，不会锁表影响业务。

mysqldump -u用户名 -p --single-transaction --routines --triggers --all-databases > full_backup.sql

这个命令跑的时候，业务完全不受影响。用户该下单下单，该评论评论，你这边安安静静地把底子打好。

第二步，配置主从同步，让新服务器追数据。

把全量备份恢复到新服务器之后，你在新服务器上把它配置成旧服务器的从库。MySQL的GTID主从复制会从你备份的那个时间点开始，源源不断地把旧服务器上的增量变更同步过来。

配置好之后，你用 show slave status 命令观察 Seconds_Behind_Master 这个指标。它在不断下降，说明新服务器正在追赶旧服务器的数据。等它降到0，就意味着两边的数据完全一致了。

第三步，选个低峰期，切换写入。

等到同步追平之后，你就可以在凌晨或者业务低谷的时候，把旧服务器的应用程序停掉(或者改成只读模式)，等最后一点点数据同步完，然后把DNS或者负载均衡切到新服务器上。

这个方案的好处是，真正的停机时间可能只有一两分钟，甚至更短。用户几乎感知不到你在背后搞了这么大的动作。

四、别忘了给你的传输“加加速”

新加坡到国内或者到其他东南亚国家，虽然网络条件在亚太地区算是不错的，但毕竟还是跨境传输。有时候光靠rsync默认参数，速度还是上不去。我试过几个提速的方法，效果比较明显的是下面这几个。

开启压缩传输。rsync的 -z 参数一定要带上，尤其是你的数据里有很多文本文件、代码、日志的时候，压缩率能达到百分之六七十，实际传输的数据量大大减少。

调整TCP参数。在传输之前，去两边的服务器上把TCP拥塞控制算法改成bbr。这个算法在高延迟、有丢包的网络环境下表现比传统的cubic好很多。顺便把TCP窗口也调大一些，让传输可以更“奔放”。

命令很简单：

modprobe tcp_bbr

echo "tcp_bbr" >> /etc/modules-load.d/modules.conf

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf

echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

sysctl -p

实测在丢包率百分之一左右的线路上，开启BBR能让传输速度提升百分之三十到五十。

五、迁移前后的检查清单，都是踩坑换来的经验

说了这么多怎么传，最后我想给你列一个检查清单。这些都是我踩过坑之后才养成的习惯。

迁移前，先把目标服务器的DNS TTL值调低。默认的TTL可能是3600秒甚至更长。你在切换之前一天，把TTL改成60或者300秒。这样等你真正切IP的时候，新的DNS记录几分钟内就能在全球生效，而不是等一个小时。

迁移中，记得校验数据一致性。文件传完之后，用 rsync 再带 --checksum 参数跑一遍。它会对比文件的校验和，确保每一个字节都对得上。对于数据库，在切换之前比对一下新旧服务器上的关键表的行数，心里有个底。

迁移后，不要把旧服务器急着关机。让它继续跑个两三天，作为备份。万一新环境出了什么意料之外的问题，你可以秒级回切，把DNS改回去，业务立即恢复。等新环境稳定运行一周之后，再来处理旧服务器。

六、最后

那次1.2T数据的迁移，最后我用了rsync配合数据库主从复制，实际停机时间控制在了十五分钟左右。用户那边只感觉到了一个短暂的“刷新一下就好了”，没有任何投诉。

回过头来看，所谓“快速同步”，其实并不依赖于某个神奇的、一键搞定的工具。它依赖的是对业务流程的理解、对工具特性的熟悉，以及最重要的是——充分的规划和测试。

新加坡大带宽服务器本身的网络质量已经给你提供了很好的基础。大带宽意味着你不会被传输速度卡脖子，但怎么用好这个带宽、怎么保证数据不丢、怎么让用户没感觉，这些还得靠你的策略。