Postgres使用pg_basebackup执行备份失败问题排查求助

报错直接指向PostgreSQL服务端的max_wal_senders参数阈值被打满，该参数定义了服务端允许同时运行的WAL发送进程最大数量，pg_basebackup执行备份时默认会占用1个WAL发送连接，无空闲连接时就会触发该报错。常见的连接占用场景包括：

• 已部署的从库流复制、逻辑复制任务长期占用WAL发送连接，总用量已经达到当前配置的10个上限
• 历史pg_basebackup备份任务异常中断，没有正常释放服务端的WAL发送进程，僵尸连接长期占用名额
• 其他WAL消费工具（如pg_receivewal）并发运行，额外占用了WAL发送连接
• 单机无外部复制的场景下，基本可以判定为异常备份任务遗留的僵尸进程占满了连接额度

先执行以下SQL确认当前WAL发送连接的使用情况：

1. 统计当前已使用的WAL发送连接总数：

SELECT count(*) FROM pg_stat_activity WHERE backend_type = 'walsender';

2. 查看所有WAL发送进程的详细信息，识别异常连接：

SELECT pid, application_name, client_addr, state, backend_start, state_change 
FROM pg_stat_activity 
WHERE backend_type = 'walsender';

返回结果中运行时长远超正常备份周期、状态长期无变化的进程，即可判定为僵尸连接。

临时解决方案（快速恢复备份能力） #

确认是僵尸连接占用的场景下，手动终止异常进程释放连接即可，将以下命令中的异常进程PID替换为上一步查询到的PID：

SELECT pg_terminate_backend(异常进程PID);

连接释放后即可正常执行pg_basebackup备份任务。

永久解决方案 #

• 调整max_wal_senders参数到符合业务需求的数值，需要覆盖从库复制、备份任务、逻辑复制、WAL归档工具等所有需要用到WAL发送连接的场景：
  1. 编辑postgresql.conf配置文件，修改参数值：

  max_wal_senders = 20  # 可根据实际业务需求调整大小
  

  2. 同步确认max_replication_slots参数值不小于max_wal_senders，避免复制槽相关报错
  3. 重启PostgreSQL服务使配置生效，根据部署方式执行对应命令，示例：

  systemctl restart postgresql
  

• 优化备份任务逻辑：增加备份前的WAL连接占用检查，避免同时触发多个pg_basebackup任务；增加备份异常中断后的连接清理逻辑，避免僵尸进程残留。

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