二次使用pg_basebackup恢复PostgreSQL时遇无效记录长度错误求助

云上老周

2026-7-6

问题：pg_basebackup恢复时出现"invalid record length at 0/D00027B: wanted 24, got 0"错误

我按照PostgreSQL官方文档搭建warm standby离线同步机制，已创建主、从两个集群。首次将主库基础备份恢复到从库，主库新增数据后恢复成功；但第二次主库添加数据后执行恢复，触发以下错误，从库未同步数据：

"invalid record length at 0/D00027B: wanted 24, got 0"

已验证初始备份完整性并重试恢复，均失败。

主库postgresql.conf配置：

wal_level = "replica"
archive_mode = on
archive_command = "copy %p c:\\Users\\myuser\\desktop\\pg_log_primary\\%f"

从库postgresql.conf配置：

wal_level = "replica"
restore_command = "copy c:\\Users\\myuser\\desktop\\pg_log_primary\\%f %p"
recover_target_timeline = 'latest'

排查步骤

检查归档目录的WAL文件完整性
错误中的0/D00027B对应WAL文件的物理位置，先定位该位置所属的WAL文件（例如00000001000000000000000D），验证文件大小是否符合标准（默认每个WAL文件为16MB，若修改过wal_segment_size则以配置值为准）。如果文件远小于标准大小，说明该WAL未完整归档。
验证主库归档命令的可靠性
你使用Windows的copy命令归档WAL，需确认：
- 目标目录c:\\Users\\myuser\\desktop\\pg_log_primary存在且主库进程具备读写权限
- 查看主库pg_log目录下的日志，检查是否有WAL归档失败的记录
- copy命令在Windows下遇到文件占用时可能静默失败，建议添加日志输出捕获错误
确认备份与WAL的时间线一致性
第二次恢复时，需确保基础备份对应的时间点之后的所有WAL文件都已完整归档。备份完成时主库会自动切换WAL，生成结束备份的记录，该记录所在的WAL必须完整归档，否则恢复时会缺失后续记录。
检查从库恢复的权限与路径
确认从库进程有权限读取归档目录的WAL文件，手动执行一次restore_command中的copy语句，验证是否能正常将WAL文件复制到从库的pg_wal目录。

替换为更可靠的归档命令
将主库的archive_command改为带错误捕获的版本，确保WAL完整归档：

archive_command = "copy %p c:\\Users\\myuser\\desktop\\pg_log_primary\\%f || echo Archive failed for %p >> c:\\pg_archive_errors.log"

或使用robocopy提升可靠性：

archive_command = "robocopy %~dp0 c:\\Users\\myuser\\desktop\\pg_log_primary\\ %~nxp > nul"

重新生成完整基础备份
若之前的备份对应的WAL已损坏或丢失，在主库重新执行pg_basebackup生成新备份，确保备份过程中主库正常归档WAL，再将新备份恢复到从库后尝试同步。
验证WAL文件有效性
使用pg_waldump工具检查报错位置对应的WAL文件：
```
pg_waldump 00000001000000000000000D
```
若工具报错，说明该WAL损坏，可手动在主库切换WAL（SELECT pg_switch_wal();）等待完整归档，或从主库的pg_wal目录重新复制该文件到归档目录。
检查从库恢复配置
确保restore_command中的路径完全正确，避免因路径大小写、转义符问题导致无法读取WAL文件。

内容的提问来源于stack exchange，提问作者Abdulaziz A Al-mekhlafi