PostgreSQL时间线损坏：除pg_basebackup外的更佳修复方案？

错误日志 #

2024-08-27 12:27:41.521 CEST [1] LOG:  启动PostgreSQL 14.12 (Debian 14.12-1.pgdg120+1) 于x86_64-pc-linux-gnu，由gcc (Debian 12.2.0-14) 12.2.0编译，64位
2024-08-27 12:27:41.526 CEST [1] LOG:  监听IPv4地址"0.0.0.0"，端口5432
2024-08-27 12:27:41.535 CEST [1] LOG:  监听IPv6地址"::"，端口5432
2024-08-27 12:27:41.555 CEST [1] LOG:  监听Unix套接字"/var/run/postgresql/.s.PGSQL.5432"
2024-08-27 12:27:41.566 CEST [27] LOG:  数据库系统已于2024-08-27 12:27:08 CEST关闭
2024-08-27 12:27:41.570 CEST [27] LOG:  进入standby模式
2024-08-27 12:27:41.570 CEST [27] FATAL:  请求的timeline 7并非本服务器历史的子节点
2024-08-27 12:27:41.570 CEST [27] DETAIL:  最新检查点位于timeline 6的2C/8B000028，但在请求的时间线历史中，服务器在2C/7C000060处分叉出该时间线。
2024-08-27 12:27:41.575 CEST [1] LOG:  启动进程（PID 27）以退出码1退出
2024-08-27 12:27:41.576 CEST [1] LOG:  因启动进程失败，中止启动
2024-08-27 12:27:41.712 CEST [1] LOG:  数据库系统已关闭

问题根源 #

主库在WAL位置2C/7C000060处分叉生成了新时间线7，但备库在主库完成分叉后，仍在旧时间线6上继续应用WAL日志，直到检查点2C/8B000028。此时备库的时间线历史与主库的新时间线没有继承关系，导致备库无法进入standby模式。

无需执行pg_basebackup的修复方法 #

方法一：使用pg_rewind快速同步（优先推荐） #

这是最高效的修复方式，前提是主备库满足以下任一条件：

• 主备库均开启wal_log_hints = on
• 数据库初始化时启用了data_checksums = on

操作步骤：

1. 停止备库服务

   pg_ctl stop -D /var/lib/postgresql/14/main
   

2. 执行pg_rewind命令，将备库数据同步至主库当前状态

   pg_rewind -D /var/lib/postgresql/14/main --source-server='host=主库IP地址 port=5432 user=复制账号 password=复制密码 dbname=postgres'
   

3. 确认备库配置正确：
   • PostgreSQL 12及以上版本：检查postgresql.conf中的primary_conninfo是否指向主库，且备库数据目录下存在standby.signal文件
   • 旧版本：检查recovery.conf中的primary_conninfo配置，并设置recovery_target_timeline = 'latest'
4. 启动备库

   pg_ctl start -D /var/lib/postgresql/14/main
   

方法二：手动回退至分叉点并切换时间线 #

如果pg_rewind无法使用（比如未开启必要参数），可尝试手动操作：

1. 停止备库服务
2. 将备库回退至主库分叉点2C/7C000060之前的状态：
   • 查看备库pg_wal目录下的WAL文件，结合pg_controldata /var/lib/postgresql/14/main输出确认当前位置，删除或回退分叉点之后的WAL数据
3. 从主库pg_wal目录复制00000007.history文件到备库的pg_wal目录
4. 修改备库配置文件：
   • PostgreSQL 12及以上：在postgresql.conf中添加recovery_target_timeline = '7'
   • 旧版本：在recovery.conf中设置recovery_target_timeline = '7'
5. 启动备库，此时备库会从分叉点开始应用主库时间线7的WAL日志

何时需要使用pg_basebackup #

只有出现以下情况时，才需要重新执行基础备份：

• 备库的WAL文件已被清理，无法回退至分叉点
• pg_rewind执行失败且手动回退操作不可行
• 主备库数据差异过大，修复成本高于重新备份

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