☰

Postgresql 9.3 热备用上的日志传送

tag-icon • tag-icon postgresql database-replication log-shipping postgresql-9.3
Postgresql 9.3 热备用上的日志传送

我的设置

我刚刚第一次在 postgres 中设置流复制（9.3.5），虽然流复制按我预期的方式工作，但我正在努力让我的备用服务器运行 archive_command，以便我可以存储所有日志文件。

主 postgres.conf：

wal_level = hot_standby
checkpoint_segments = 8
max_wal_senders = 4
wal_keep_segments = 8

备用postgres.conf：

wal_level = hot_standby
checkpoint_segments = 8
archive_mode = on
archive_command = 'test ! -f /backup/postgres_archive/constant/%f && cp %p /backup/postgres_archive/constant/%f'
max_wal_senders = 3
wal_keep_segments = 8
hot_standby = on

备用恢复.conf：

standby_mode = 'on'
primary_conninfo = 'host=my-host.example.com port=5432 user=replicator password=my_password sslmode=require'
restore_command = 'cp /backup/postgres_archive/constant/%f %p'
trigger_file = '/tmp/postgresql.trigger'

我尝试写入的文件夹的权限是正确的，当我以 postgres 用户身份手动运行 archive_command 时，它工作正常。为确保万无一失，我尝试将 archive 命令更改为 simple touch（再次以 postgres 用户身份测试成功），但没有任何变化。

正在发挥作用的事情

我的数据库还处于相对初级阶段，因此负载并不大。为此，我只是通过将随机数据写入测试表来模拟它。在主服务器上提交后，我可以看到更改立即出现在备用服务器上，所以我对此感到满意。

我不太明白的一件事是，备用服务器和主服务器的 WAL 文件略有不同，但看起来好像其中一个服务器配置了一个尚未开始写入的 WAL（另一个服务器没有）。这正常吗？

如果我select pg_switch_xlog()在主服务器上执行此操作，然后再写入一些内容，主服务器和备用服务器似乎都会切换并开始写入下一个/相同的 WAL 文件。所以这反映了我对正在发生的事情的理解。

帮助

我对此有几个疑问。我已阅读了有关此问题的 Postgres 手册的每一页，但我找不到任何能帮助解决我特定情况的内容。

我尝试找到某种方法让 postgres 在日志文件中显示有关它可能正在做什么/不做什么的更多信息，但没有得到任何有用的信息。在调试时，我应该在配置中更改什么才能将尽可能多的有用信息放入日志中？

至于日志归档何时运行，我猜是因为主服务器控制哪个 WAL 文件处于活动状态，因此它实际上是日志传送在备用服务器上运行的触发器。对吗？

流式复制似乎都按我预期的方式工作，但尝试在备用服务器上运行日志传送似乎根本无法成功。我做错了什么？

答案1

我也刚遇到过这个问题。这里的关键实际上是archive_cleanup_command备用服务器上的“recovery.conf”。备用服务器archive_cleanup_command在处理完主服务器上的 WAL 段后将运行该命令，因此此时您知道可以备份该 WAL 段和所有先前的段。在我的“recovery.conf”中，我有：

archive_cleanup_command = '/var/lib/postgresql/wal_backup_mirror.sh "%r"'

该脚本的内容如下（简化版本）：

CURRENT_WAL_FILE="$1"
for WAL_FILE in $(find /pg_logs/main -maxdepth 1 -type f | sort | awk "\$0 <= \"/pg_logs/main/${CURRENT_WAL_FILE}\""); do
  WAL_NAME=$(basename "$WAL_FILE")
  gzip -c "$WAL_FILE" > "/backups/wal/${WAL_NAME}.gz"
  #now upload the just created .gz to S3 or some other offsite storage

  rm -f "${WAL_FILE}"
done

请注意，我在备份 WAL 段之后删除了它，以使备用服务器上的日志目录保持干净，但需要注意的是，要小心级联复制设置，因为链下更远的备用服务器可能仍然需要这些文件。

最后要注意的是，备份 WAL 段是不够的，必须结合某种常规完整备份 (pg_basebackup) 来完成。我们每天都会进行完整备份，然后根据需要在一天中备份 WAL 段。

相关内容