从PostgreSQL 17到18：详解pg_upgrade的5种数据迁移模式（--copy/--link/--clone/--swap/--copy-file-range）

从PostgreSQL 17到18：详解pg_upgrade的5种数据迁移模式（--copy/--link/--clone/--swap/--copy-file-range）

每次PostgreSQL大版本升级，对数据库管理员来说都是一次技术决策的考验。传统的数据迁移方式往往意味着数小时甚至数天的停机时间，这对于现代业务系统来说几乎是不可接受的。PostgreSQL社区一直在努力降低升级的复杂度与停机时间，而pg_upgrade工具正是这一努力的结晶。

从早期的简单文件复制，到后来的硬链接优化，再到如今PostgreSQL 18引入的--swap模式，pg_upgrade已经发展成为一个拥有五种不同数据迁移策略的成熟工具集。每种模式都有其独特的适用场景、性能特征和限制条件，理解这些差异对于制定高效的升级方案至关重要。

本文将从技术原理、性能表现、适用场景三个维度，深入剖析这五种迁移模式。无论你是在本地SSD上运行的小型数据库，还是在AWS EBS或NFS共享存储上的企业级集群，都能找到最适合你的升级路径。

1. 五种迁移模式的技术原理深度解析

要理解不同迁移模式的优劣，首先需要了解PostgreSQL数据文件的基本结构。一个PostgreSQL集群的数据目录包含两类核心文件：系统表文件（存储元数据）和用户数据文件（存储实际表数据）。升级过程中，系统表需要完全重建以适应新版本的数据结构，而用户数据文件在大多数情况下可以保持原样。

1.1 传统复制模式：--copy

--copy是pg_upgrade的默认模式，也是最保守、最安全的选择。它的工作原理非常简单直接：

# 典型的--copy模式升级命令
pg_upgrade \
  -b /usr/lib/postgresql/17/bin \
  -B /usr/lib/postgresql/18/bin \
  -d /var/lib/postgresql/17/main \
  -D /var/lib/postgresql/18/main \
  --copy

在这种模式下，pg_upgrade会执行以下关键操作：

1. 创建新的系统表：基于旧集群的元数据生成新版本的系统表结构
2. 逐文件复制用户数据：使用标准的文件复制操作将每个数据文件从旧目录复制到新目录
3. 更新文件头信息：修改复制后的文件头以匹配新版本的格式要求
4. 清理临时文件：删除升级过程中产生的中间文件

注意：--copy模式会在磁盘上创建完整的数据副本，这意味着你需要至少两倍于原数据库大小的可用磁盘空间。对于TB级别的数据库，这可能会成为严重的限制因素。

从文件系统层面看，--copy模式的操作流程如下表所示：

这种模式的最大优势在于安全性——即使升级过程中出现任何问题，原始数据文件完全不受影响，可以随时回退到旧版本。但代价是时间和空间的双重开销，特别是在处理大量小文件时，文件系统元数据操作会成为显著的性能瓶颈。

1.2 硬链接模式：--link

--link模式是PostgreSQL早期版本中引入的优化方案，它通过文件系统的硬链接机制来避免实际的数据复制：

# 使用--link模式进行升级
pg_upgrade \
  -b /usr/lib/postgresql/17/bin \
  -B /usr/lib/postgresql/18/bin \
  -d /var/lib/postgresql/17/main \
  -D /var/lib/postgresql/18/main \
  --link

硬链接的本质是多个目录项指向同一个inode。在--link模式下：

1. 创建硬链接而非复制：对于每个用户数据文件，在新目录中创建一个指向原文件inode的硬链接
2. 独立修改系统表：系统表文件仍然需要新建，因为它们的结构发生了变化
3. 文件内容共享：新旧集群共享同一份物理数据，直到其中一个集群修改文件内容

这里有一个关键的技术细节：当新集群启动并开始写入时，写时复制（Copy-on-Write）机制会触发。PostgreSQL使用8KB的数据页，当新集群需要修改某个数据页时，文件系统会为该页创建副本，而其他未修改的页继续保持共享。

硬链接模式的核心限制：

• 要求新旧数据目录必须位于同一个文件系统（同一个挂载点）
• 一旦新集群启动，旧集群将无法再安全启动
• 不支持跨文件系统的表空间迁移

我在一次生产环境升级中遇到过这样的场景：一个500GB的数据库，使用--copy模式预计需要3小时，而使用--link模式仅需15分钟。但代价是失去了快速回退的能力——一旦新集群启动，旧集群的数据文件就被"污染"了。

1.3 克隆模式：--clone

--clone模式是近年来随着现代文件系统发展而引入的新特性，它依赖于文件系统的写时复制（CoW） 能力：

# 使用支持reflink的文件系统进行克隆升级
pg_upgrade \
  -b /usr/lib/postgresql/17/bin \
  -B /usr/lib/postgresql/18/bin \
  -d /var/lib/postgresql/17/main \
  -D /var/lib/postgresql/18/main \
  --clone

并非所有文件系统都支持克隆操作。目前已知的支持情况如下：

克隆模式的工作原理与硬链接类似，但在文件系统层面有本质区别。硬链接是共享inode，而克隆是创建共享数据块但独立inode的引用。这意味着：

1. 即时完成：克隆操作几乎是瞬间完成的，无论文件大小
2. 独立元数据：新旧文件有各自的inode、权限、时间戳等元数据
3. 写时分离：当任一集群修改文件时，只有被修改的数据块会被复制

技术提示：要检查你的文件系统是否支持reflink，可以尝试以下命令：

# 创建一个测试文件
dd if=/dev