如何将Oracle Linux7.9上PostgreSQL13的5TB数据迁移至Ubuntu24上的PostgreSQL17？

DevOps 小满

2026-6-14

PostgreSQL 13→17 大数据量低停机迁移最佳方案

针对你5TB关键数据、最小停机时间的需求，全量物理备份+逻辑复制增量同步是最优方案，远优于pg_dump/pg_restore。以下是具体实施步骤、方案对比及避坑建议：

一、核心方案：全量备份+逻辑复制追平+快速切换

该方案仅在最终业务切换阶段产生极短停机，整体迁移过程几乎不影响源端业务。

目标端配置：部署PostgreSQL 17，对齐源端核心参数（如shared_buffers、work_mem），并开启逻辑复制所需配置：
在postgresql.conf中添加：
```
wal_level = logical
max_replication_slots = 10  # 至少预留1个迁移用槽位
max_wal_senders = 10       # 足够的WAL发送进程
```
重启目标端PG服务生效。
源端配置：PG13默认wal_level为replica，需改为logical，重启源端服务（此步骤有几秒停机，提前规划窗口）。

复制权限配置：源端创建复制专用角色并授权：

CREATE ROLE repl_user WITH REPLICATION LOGIN PASSWORD 'your_secure_pwd';

在pg_hba.conf中允许目标端IP访问：

host    replication     repl_user     目标端IP/32     scram-sha-256

重载源端配置：pg_ctl reload

源端在线全量备份：用pg_basebackup做物理备份，不影响源端业务：
```
pg_basebackup -h 源端IP -U repl_user -D /tmp/pg_full_backup -P -X stream
```

传输备份到目标端：优先用rsync（断点续传适合大文件）：

rsync -avz /tmp/pg_full_backup/ 目标端postgres用户@目标端IP:/var/lib/postgresql/17/main/

目标端恢复并同步：调整备份目录权限为postgres用户，配置流复制追平：
```
chown -R postgres:postgres /var/lib/postgresql/17/main/
```
在目标端postgresql.conf添加：
```
primary_conninfo = 'host=源端IP port=5432 user=repl_user password=your_secure_pwd application_name=migrate_replica'
```
创建恢复信号文件启动同步：
```
touch /var/lib/postgresql/17/main/recovery.signal
```
启动目标端PG服务，此时目标端会作为源端的流复制副本，实时追平数据。

暂停源端写入（如将业务切为只读或临时停应用），这是唯一的停机窗口。
确认数据完全同步：
源端执行：SELECT pg_current_wal_lsn();
目标端执行：SELECT pg_last_wal_replay_lsn();
当两个值相等时，数据完全一致。
提升目标端为主库：
```
SELECT pg_promote();
```
切换业务流量到目标端PG17，验证正常后，可停止源端服务或留作备份。

网络优化：源端与目标端优先用内网万兆网络，跨公网时需启用备份压缩（pg_basebackup -z）减少传输量。
磁盘IO优化：两端均使用SSD存储，避免IO瓶颈拖慢备份、恢复速度；目标端恢复时可临时调大maintenance_work_mem（如4GB）加速索引重建。
兼容性检查：提前排查PG13到PG17的版本差异，比如废弃函数（如pg_stat_statements旧版语法）、配置参数变化，可先用测试库验证。
数据校验：切换完成后，通过对比表行数、关键字段哈希值（如SELECT md5(CAST((table_name)AS text)) FROM information_schema.tables;）确认数据一致性，或使用pg_checksums校验。
回滚预案：切换前保留源端完整备份，且源端在切换前保持只读状态一段时间，确保出现问题时能快速切回。

内容的提问来源于stack exchange，提问作者Pramod Vinay