PostgreSQL大数据迁移指南:跨版本跨平台(5TB, PG13-17)
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
则将这些脚本或归档文件导入到新数据库。 -
步骤:
- 在 Oracle Linux 7.9 上,使用
pg_dump
导出数据:pg_dump -U postgres -d mydatabase -Fc -f mydatabase.dump
-Fc
参数表示使用自定义归档格式,可以并行导入,更快。 - 将
mydatabase.dump
文件传输到 Ubuntu 24 服务器。 - 在 Ubuntu 24 上,使用
pg_restore
导入数据:pg_restore -U postgres -d newdatabase -j 4 -Fc mydatabase.dump
-j 4
参数表示使用 4 个并行进程导入,可以加速。(根据服务器 CPU 核心数调整) - 在ubuntu下运行postgrsql17的更新指令
pg_upgrade
- 在 Oracle Linux 7.9 上,使用
-
优点: 简单直接,易于理解和操作。
-
缺点: 停机时间长,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 集群的全局对象。 - 步骤:
- 在 Oracle Linux 7.9 上,使用
pg_dumpall
导出全局对象:pg_dumpall -U postgres -g -f global_objects.sql
- 将
global_objects.sql
传输到 Ubuntu 24 服务器。 - 在 Ubuntu 24 上,先导入全局对象,再使用方案 1 的
pg_restore
导入数据:psql -U postgres -f global_objects.sql
- 在 Oracle Linux 7.9 上,使用
3. 使用逻辑复制 (pglogical 或 内置逻辑复制)
这个方法可以实现近乎实时的迁移,停机时间最短。
-
原理: 在源数据库和目标数据库之间建立逻辑复制关系。源数据库上的更改会实时同步到目标数据库。
-
步骤 (以 PostgreSQL 内置逻辑复制为例):
- 在源数据库 (PostgreSQL 13) 上:
- 修改
postgresql.conf
文件:wal_level = logical max_replication_slots = 4 # 根据需要调整 max_wal_senders = 4 # 根据需要调整
- 重启 PostgreSQL 服务。
- 创建发布 (Publication):
CREATE PUBLICATION my_publication FOR ALL TABLES;
- 修改
- 在目标数据库 (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;
- 创建与源数据库相同的表结构(可以先用
- 等待数据同步完成。
- 在业务低峰期,切换应用到目标数据库,停止源数据库的写入。
- 停掉原来的订阅服务。
- 在源数据库 (PostgreSQL 13) 上:
-
优点: 停机时间最短,几乎可以做到无缝切换。
-
缺点: 配置稍微复杂,需要对 PostgreSQL 逻辑复制有一定了解。而且可能存在一些限制,一些老扩展,在新数据库中不能使用。
-
安全建议: 在创建连接字符串时,务必使用强密码,并通过安全通道 (例如 VPN 或 SSH 隧道) 连接。
-
进阶用法: 逻辑复制提供了一些进阶特性来提高迁移的可靠性和效率,但同时也会增加复杂度,需要更谨慎地规划和测试。
- 双向复制 : 如果担心回滚,可以在迁移期间配置双向复制。这意味着源数据库和目标数据库之间互相复制数据。
- 冲突解决 : 双向复制或者多源复制情况下发生数据冲突,就需要合理的冲突解决策略。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 编写的,并且由于它是预编译的,因此具有出色的性能。
这些工具通常提供了图形化界面和更丰富的功能,但可能需要付费或许可。
选择建议
- 如果可以接受较长的停机时间 (例如几个小时): 选方案 1 (pg_dump / pg_restore)。简单省事。
- 如果要求最小化停机时间: 选方案 3 (逻辑复制)。
- ** 如果追求速度,不在乎操作系统是否一样** 可以使用方案4
- 需要考虑自己是否有预算进行商业迁移
注意事项
- 备份! 备份! 备份! 迁移前务必完整备份源数据库,以防万一。
- 测试! 测试! 测试! 在正式迁移前,务必在测试环境模拟整个迁移过程,确保一切顺利。
- 监控: 在迁移过程中,密切监控数据库性能和复制状态。
- 字符集和排序规则: 确保源数据库和目标数据库的字符集和排序规则一致,避免数据乱码。
- 扩展: 确保目标数据库安装了所有源数据库中使用的扩展。
- 检查ubuntu服务器和oracle服务器的硬件差距,以免性能不升反降。
祝你迁移顺利!