在PostgreSQL的WAL（Write Ahead Log）机制中，归档进程会把写满的WAL段文件复制到指定目录，用于备份与恢复。这些归档文件的名字并不是随意生成的，而是遵循一套固定的十六进制编码规则。只有弄清楚它的组成结构，运维人员才能在海量归档中快速定位需要的日志，也能在编写清理策略时做到不误删、不漏删。
一、归档功能的基本配置
要让PostgreSQL产生归档文件，首先必须在配置文件postgresql.conf中开启相关参数。最核心的三个参数是wal_level、archive_mode和archive_command。wal_level决定WAL记录的详细程度，若要支持归档及流复制，至少应设为replica；archive_mode设为on表示启用归档；archive_command则是 shell 命令模板，用%p代表源WAL路径，%f代表文件名。
举例来说，下面这段配置会把WAL文件拷贝到本地/var/lib/pgsql/archive目录中：
-- postgresql.conf 中的关键配置 wal_level = replica archive_mode = on archive_command = 'cp %p /var/lib/pgsql/archive/%f'
修改后需要重启或重载配置才能生效。需要注意的是，archive_command执行成功（返回0）数据库才认为该文件已归档，否则会不断重试。因此命令里最好加上校验逻辑，避免磁盘满或权限问题导致归档卡住。
二、归档文件名的分段含义
一个典型的归档文件名如000000010000000000000003，总长度为24位十六进制字符。它可以精确拆分为三个部分：前8位为时间线ID（Timeline ID），中间8位为逻辑日志文件号（Logical Log File Number），后8位为段内偏移（Segment Number，通常固定为0，除非使用了非默认段大小）。
时间线可以理解为数据库历史的分支编号。每次做时间点恢复（PITR）或主备切换，时间线就会加一，例如从00000001变成00000002。逻辑日志文件号则随WAL写入量单调递增，每写满一个文件（默认16MB）就加一。段内偏移在默认配置下总是00000000，仅在自定义WAL段大小时才会出现非零值。下表给出具体拆解：
| 文件名片段 | 含义 | 示例值 |
|---|---|---|
| 00000001 | 时间线ID | 1号时间线 |
| 00000000 | 逻辑日志文件号高位 | 第0组 |
| 00000003 | 逻辑日志文件号低位及段偏移 | 第3个段文件 |
通过这种命名，管理员能直接看出某个归档属于哪条时间线、处于哪个日志序号。在恢复时，PostgreSQL会根据backup_label里记录的时间线去归档目录寻找匹配前缀的文件。
三、时间线切换对命名的影响
当执行PITR或者发生failover promotion时，数据库会切换到新时间线，此后生成的WAL文件名前缀随之改变。假设原库时间线是1，恢复后变成2，那么新归档就会以00000002开头。旧时间线的文件仍然保留，方便回退到更早的状态。
这也带来一个常见误区：有些人写清理脚本时用rm命令删除“最旧”的文件，却只按修改时间排序，忽略了时间线前缀。结果把刚切换时间线后的早期文件删掉，导致新时间线恢复链断裂。正确的做法是基于文件名解析出时间线与日志号，结合当前备份所依赖的最小日志号来判定保留范围。
#!/bin/bash
# 简单解析归档文件名的时间线与日志号
fname="00000002000000010000002A"
timeline=${fname:0:8}
lognum=${fname:8:16}
echo "时间线: $timeline"
echo "日志号: $lognum"
上面这段脚本演示了如何用shell字符串截取拿到关键字段。实际生产中可以把它放进Python或Go写的巡检工具里，定期扫描归档目录并输出每个文件对应的时间线分布图。
四、解析与运维实践建议
理解了命名规则后，建议在备份体系中记录每次基础备份的起始时间线及起始WAL文件名。这样在需要恢复时，可以精确知道要取哪一段归档。同时，使用pg_archivecleanup工具时务必指定正确的备份文件名，它会自动识别时间线并清理不再需要的旧归档。
另外，如果开启了归档压缩，文件名本身不变，只是内容被压缩，此时解析逻辑完全一致。对于使用对象存储作为归档目标的情况，也应以文件名为准设计目录结构，比如按时间线建子目录，避免所有文件平铺在一个桶里难以检索。只有把命名规则吃透，整个备份恢复链路才真正可控。
PostgreSQL归档文件wal_level修改时间：2026-08-11 07:06:29