www.876873.xyz

📦 阵营一：被完整打包的核心数据（在 $PGDATA 内部）

这是数据库的“肉身”，pg_basebackup 会毫不犹豫地将它们按原样复制（或打包成 base.tar）：

• base/：默认表空间。里面按 OID 存放了你创建的各个数据库的真实表数据和索引数据（也就是那些 8KB 的数据块）。
• global/：全局字典。包含整个集群的共享系统表（如 pg_database、pg_authid 角色密码等）以及控制文件 pg_control（记录了极其关键的 Checkpoint LSN 和数据库状态）。
• pg_xact/ (旧版本叫 pg_clog)：事务提交状态（Commit Log）。记录了每个事务 ID（XID）是提交了还是回滚了，这是 MVCC 判别数据可见性的基础。
• pg_multixact/：多事务状态。用于处理行级共享锁并发。
• pg_twophase/：两阶段提交（2PC）的准备状态文件。
• 配置文件：如果你的 postgresql.conf、pg_hba.conf、pg_ident.conf 存放在 $PGDATA 目录下，它们会被一并备份。

---

🚀 阵营二：跨越目录边界的数据（在 $PGDATA 外部）—— 极其关键的考点

这就是打破“只备份 $PGDATA”认知的关键所在：表空间（Tablespaces）。

如果你在数据库中使用了外部表空间（例如，将核心订单表存放在了极速 SSD 挂载的目录 /data/ssd_01 下），此时 $PGDATA/pg_tblspc/ 目录下会有一个指向 /data/ssd_01 的软链接。

当 pg_basebackup 运行到这里时，它的底层物理动作是：

1. 顺藤摸瓜：它不会只傻傻地备份一个软链接，它会顺着软链接冲出 $PGDATA，来到 /data/ssd_01。
2. 物理拷贝：它会将 /data/ssd_01 里面的所有真实数据文件全部备份下来！
   • 如果使用纯文本格式（-F p），它会原样拷贝目录。
   • 如果使用 tar 格式（-F t），它会单独生成一个以表空间 OID 命名的压缩包（比如 16384.tar），与主目录的 base.tar 并列存放。

---

🗑️ 阵营三：被内核“精准剔除”的垃圾与状态文件

pg_basebackup 不是简单的 cp -r 命令。PostgreSQL 内核非常聪明，它知道哪些文件是**“当前运行实例专属的、不能带到备份机上的”，在备份时会极其严厉地将它们物理跳过**：

1. 进程锁文件：postmaster.pid、postmaster.opts。备份如果带上 PID 文件，在新机器上解压后会导致无法开机（报错提示 PG 正在运行）。
2. 统计信息缓存：pg_stat_tmp/ 目录下的所有文件。这是运行时的实时统计缓存，备份它毫无意义。
3. 复制槽数据：pg_replslot/ 目录下的所有内容。**这是个大坑！**主库的复制槽状态绝对不能带给从库或备份，否则会引发严重的 WAL 日志回收混乱。
4. 临时文件：pgsql_tmp/（执行大 SQL 产生的磁盘排序临时文件），备份这些只是在浪费空间。
5. 缓存字典：pg_internal.init（各个数据库目录下的系统表缓存文件），启动时会自动重建。
6. 日志文件：默认配置下的 log/ 或 pg_log/ 目录的内容通常会被跳过（因为排错日志不需要用来恢复数据）。

---

📜 阵营四：WAL 日志的特殊处理（pg_wal/）

对于 $PGDATA/pg_wal/（存储重做日志的目录），它是否被备份，完全取决于你敲下命令时的参数选项：

• 如果不带 -X 参数（或 -X none）：默认情况下，pg_basebackup 不包含完整的 WAL 日志。它只复制数据文件，你需要自己确保主库的归档（Archive）是正常的，否则这份备份是废渣。
• 使用 -X fetch：在备份结束的最后一刻，扫描此时需要的 WAL 文件，并把它们拷贝到备份集中。
• 使用 -X stream（生产环境绝对标配）：在备份数据文件的同时，在后台拉起一个 walreceiver 进程，通过流复制协议，把备份期间产生的 WAL 日志源源不断地实时接收过来，存放在备份集的 pg_wal 目录下（或打包成 pg_wal.tar）。