Skip to content
VDS · 数据库

从其他服务器迁移数据库

将数据库迁移到 Millida VDS 的流程:准备工作、通过网络传输转储、检查完整性,以及以最小停机时间切换应用。

更新于 2026年8月23日

数据库迁移的成败不取决于命令,而取决于步骤顺序:很多人先切换域名,之后才发现有一半数据根本没迁过来。下面这套流程可以避免这种情况。

准备工作

在新机器上安装相同或更新版本的数据库服务器——PostgreSQL 或 MySQL。不支持降级。

psql --version
mysql --version
df -h /

您需要大约数据库大小 2.5 倍的可用空间:转储文件、解压后的数据,以及一些余量。在 VDS-1 上总共是 40 GB,请提前规划。

创建一个用户和一个空数据库,编码与旧服务器保持一致。

迁移数据

最简单的方式是通过 SSH 直接转储,不产生中间文件:

ssh root@OLD 'pg_dump -Fc -U shop shop' > /srv/shop.dump
pg_restore -U postgres -d shop --no-owner --role=shop /srv/shop.dump

对于 MySQL:

ssh root@OLD 'mysqldump --single-transaction --routines --events -u root shop' \
  | mysql -u root shop

角色和用户不包含在数据库转储中——需要单独导出:pg_dumpall --roles-only,或者手动创建——参见用户与授权。

带宽最高可达 500 Mbps,因此 20 GB 的数据库几分钟就能迁移完成;瓶颈通常是磁盘写入,而磁盘写入受套餐等级限制。

切换前验证

要核对数字,而不只是看“网站能打开”:

SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 20;
SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='shop';

将关键表的行数与旧服务器对比,检查序列是否被重置(SELECT last_value FROM users_id_seq;),并在测试模式下让应用连接新数据库运行。

正式切换

  1. 在旧服务器上启用维护模式或停止应用。
  2. 对准备期间产生的变更做最后一次转储。
  3. 在新机器上恢复该转储。
  4. 切换应用的连接字符串并重启服务。
  5. 让旧服务器继续运行一周,不要删除数据。

不要跳过第五步:三天后才发现少了一张表是常有的事。

常见错误

现象原因
恢复时出现 role does not exist角色未迁移——使用 --no-owner 并手动创建角色
出现乱码编码不一致:恢复到使用 utf8mb4 或 UTF8 的数据库
序列从 1 开始转储只包含数据,没有 setval
恢复耗时数小时索引在恢复过程中即时构建;对于大型数据库请使用 pg_restore -j 4
中途空间不足没有把转储文件的大小与数据一并计算在内

迁移前,请确认新数据库只监听 127.0.0.1。没有必要“在迁移期间”将其公开暴露——传输通过 SSH 进行,参见远程访问。