我来帮你排查这个问题——这种Docker+PostgreSQL主从复制的重启故障我之前碰到过好几次，核心问题基本都围绕着初始化脚本的执行逻辑和standby状态的持久化配置这两点，咱们一步步来分析：

可能的核心原因 #

首先得明确：官方PostgreSQL镜像的docker-entrypoint-initdb.d目录下的脚本只会在容器首次启动、数据目录为空时执行一次。重启容器时，如果数据目录已经有数据（比如你挂载了持久化卷），这些脚本不会再运行。你的恢复操作首次成功，但重启后出错，大概率是从库的standby模式没有被正确持久化，或者重启后PostgreSQL无法自动进入recovery状态。

具体排查与修复步骤 #

1. 检查recovery.conf的状态（PostgreSQL 10专属） #

PostgreSQL 10还在使用独立的recovery.conf文件来配置standby模式，只要这个文件存在于数据目录，启动时就会自动进入recovery/standby状态。如果重启后这个文件消失或被重命名，就会导致从库以普通数据库启动，复制模式自然出错。

先进入从库容器检查文件是否存在：

docker exec -it <你的从库容器ID/名称> ls /var/lib/postgresql/data/recovery.conf

• 如果文件不存在：说明你的初始化脚本在完成恢复后没有保留这个文件。修改初始化脚本，在执行完pg_basebackup或恢复操作后，务必生成并写入持久化的recovery.conf，示例内容：

  standby_mode = 'on'
  primary_conninfo = 'host=<主库容器名称/IP> port=5432 user=复制账号 password=复制密码 application_name=slave'
  trigger_file = '/tmp/promote_to_master' # 可选，用于手动提升从库为主库
  

  注意：绝对不要在初始化脚本里执行pg_ctl promote命令，这个操作会把recovery.conf重命名为recovery.done，直接让从库退出standby模式。

• 如果文件存在但还是出错：打开文件检查primary_conninfo是否正确（主库地址、账号密码是否能访问），同时确认postgresql.conf里的hot_standby = on是否开启（这个参数允许从库在standby状态下提供只读服务，必须开启）。

2. 确认Docker卷的持久化配置 #

如果你的从库没有挂载持久化卷到/var/lib/postgresql/data目录，重启容器后所有数据（包括recovery.conf）都会丢失，相当于重新初始化，复制模式肯定会出错。检查你的容器启动命令或docker-compose.yml，确保有类似这样的挂载配置：

# docker-compose.yml示例片段
services:
  pg-slave:
    image: postgres:10
    volumes:
      - pg-slave-data:/var/lib/postgresql/data # 用命名卷持久化数据
      - ./init-scripts:/docker-entrypoint-initdb.d

3. 验证修复结果 #

完成上述调整后，重启从库容器，然后进入容器执行以下命令验证状态：

docker exec -it <从库容器ID> psql -U postgres -c "SELECT pg_is_in_recovery();"

如果返回结果是t，说明从库已经成功进入standby模式，复制应该能正常工作；如果返回f，再回头检查recovery.conf的存在性和配置正确性。

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