PostgreSQL大数据迁移指南：跨版本跨平台(5TB, PG13-17)

Linux

2025-03-13 02:19:19

PostgreSQL 跨版本、跨平台大数据迁移：从 Oracle Linux 7.9 (PG 13) 到 Ubuntu 24 (PG 17)

碰到了数据库迁移的硬茬？要把 5TB 的 PostgreSQL 数据库从版本 13 (Oracle Linux 7.9) 搬到版本 17 (Ubuntu 24)，还要尽量减少停机时间。这确实是个挑战！

这问题不好搞啊, 主要难点在于：

数据量大: 5TB 数据，迁移起来可不是闹着玩的，时间长。
跨版本升级: PostgreSQL 13 到 17，跨了多个大版本，兼容性问题要小心。
跨操作系统迁移: 从 Oracle Linux 7.9 到 Ubuntu 24，文件系统、配置都可能有差异。
最小化停机时间: 业务不能停太久，迁移期间的服务保障要做好。

别慌，我们来一步步分析，看看有哪些可行的方案。

一、问题原因分析

PostgreSQL 版本升级以及跨操作系统的数据迁移的难点：

不同大版本之间存在不兼容性 : 新版本可能引入新的数据类型、函数、或者改变了内部存储机制。
不同操作系统的文件系统和配置差异 ：例如,路径分隔符、权限设置等。
长时间的停机 : 直接 pg_dump 和 pg_restore 大数据库会导致很长的服务中断。

二、解决方案

咱们有几个可选方案，各有优劣，要根据实际情况来选：

1. 使用 pg_dump / pg_restore

这是最直接的办法，但也是停机时间最长的。

原理: pg_dump 将数据库导出成 SQL 脚本或自定义归档格式。pg_restore 则将这些脚本或归档文件导入到新数据库。
步骤:
1. 在 Oracle Linux 7.9 上，使用 pg_dump 导出数据：
```
pg_dump -U postgres -d mydatabase -Fc -f mydatabase.dump
```
  -Fc 参数表示使用自定义归档格式，可以并行导入，更快。
2. 将 mydatabase.dump 文件传输到 Ubuntu 24 服务器。
3. 在 Ubuntu 24 上，使用 pg_restore 导入数据：
```
pg_restore -U postgres -d newdatabase -j 4 -Fc mydatabase.dump
```
  -j 4 参数表示使用 4 个并行进程导入，可以加速。（根据服务器 CPU 核心数调整）
4. 在ubuntu下运行postgrsql17的更新指令
```
pg_upgrade
```
优点: 简单直接，易于理解和操作。
缺点: 停机时间长，5TB 数据，估计要几个小时甚至更久。

进阶使用 ：配合screen或者tmux 使用。防止意外中断导致的数据错误和浪费的时间
```bash
# 运行 Screen 命令
screen

  # 或者，运行 Tmux 命令
  tmux
  #然后把pg_dump 和 pg_restore命令放到后台
  pg_dump -U postgres -d mydatabase -Fc -f mydatabase.dump &

  pg_restore -U postgres -d newdatabase -j 4 -Fc mydatabase.dump &
  ```

2. 使用 pg_dumpall + pg_restore (仅限全局对象)

如果你的数据库有自定义的全局对象 (例如角色, 表空间)，需要分开迁移。

原理: pg_dumpall 用于导出 PostgreSQL 集群的全局对象。
步骤:
1. 在 Oracle Linux 7.9 上，使用 pg_dumpall 导出全局对象：
```
pg_dumpall -U postgres -g -f global_objects.sql
```
2. 将 global_objects.sql 传输到 Ubuntu 24 服务器。
3. 在 Ubuntu 24 上，先导入全局对象，再使用方案 1 的 pg_restore 导入数据：
```
psql -U postgres -f global_objects.sql
```

3. 使用逻辑复制 (pglogical 或内置逻辑复制)

这个方法可以实现近乎实时的迁移，停机时间最短。

原理: 在源数据库和目标数据库之间建立逻辑复制关系。源数据库上的更改会实时同步到目标数据库。
步骤 (以 PostgreSQL 内置逻辑复制为例):
1. 在源数据库 (PostgreSQL 13) 上:
  - 修改 postgresql.conf 文件：
```
wal_level = logical
max_replication_slots = 4 # 根据需要调整
max_wal_senders = 4       # 根据需要调整
```
  - 重启 PostgreSQL 服务。
  - 创建发布 (Publication)：
```
CREATE PUBLICATION my_publication FOR ALL TABLES;
```
2. 在目标数据库 (PostgreSQL 17) 上:
  - 创建与源数据库相同的表结构（可以先用 pg_dump 的 --schema-only 选项导出结构）。
  - 创建订阅 (Subscription)：
```
CREATE SUBSCRIPTION my_subscription
CONNECTION 'host=source_server_ip port=5432 user=postgres password=your_password dbname=mydatabase'
PUBLICATION my_publication;
```
3. 等待数据同步完成。
4. 在业务低峰期，切换应用到目标数据库，停止源数据库的写入。
5. 停掉原来的订阅服务。
优点: 停机时间最短，几乎可以做到无缝切换。
缺点: 配置稍微复杂，需要对 PostgreSQL 逻辑复制有一定了解。而且可能存在一些限制,一些老扩展,在新数据库中不能使用。
安全建议: 在创建连接字符串时，务必使用强密码，并通过安全通道 (例如 VPN 或 SSH 隧道) 连接。
进阶用法： 逻辑复制提供了一些进阶特性来提高迁移的可靠性和效率，但同时也会增加复杂度，需要更谨慎地规划和测试。
1. 双向复制 : 如果担心回滚，可以在迁移期间配置双向复制。这意味着源数据库和目标数据库之间互相复制数据。
2. 冲突解决 : 双向复制或者多源复制情况下发生数据冲突，就需要合理的冲突解决策略。PostgreSQL 的逻辑复制本身不提供自动的冲突解决机制，所以你需要仔细设计应用逻辑和数据模型来尽量避免冲突，或者在应用层处理冲突。

4. 使用 pg_upgrade

此方法不适用本例，因为需要跨平台。pg_upgrade 只适用于同一操作系统下的升级。但仍在这里介绍, 供参考。

原理: pg_upgrade 是 PostgreSQL 官方提供的原地升级工具，通过链接而不是复制数据文件，可以大大加快升级速度。
不适用原因: pg_upgrade 主要做 PostgreSQL 本地版本升级。跨操作系统的情况下,此方案不可用。

5. 使用第三方工具

有一些商业或开源工具可以简化数据库迁移，例如:

AWS Database Migration Service (DMS): 如果你的数据库在 AWS 上，可以考虑使用 DMS。
Qlik Replicate (原 Attunity Replicate): 商业软件，功能强大，支持多种数据库和平台。
pgloader: 一款强大的开源工具, pgloader 是用 Common Lisp 编写的，并且由于它是预编译的，因此具有出色的性能。
这些工具通常提供了图形化界面和更丰富的功能，但可能需要付费或许可。