使用读取繁重的 Slave 管理热备中 Postgres 复制的冲突和滞后

要求：

Avoid terminating connection due to conflict with recovery错误也可以接受replication lag.

Google Cloud PostgreSQL 9.6，复制已打开（使用流复制），PGPool-II 设置为仅执行负载平衡，并在从属设备上具有以下属性：

work_mem    3276800
commit_delay    100
max_wal_size    940
max_standby_archive_delay   -1
max_standby_streaming_delay -1
hot_standby_feedback    on

机器配置:

vCPU：8，内存：30 GB，SSD 存储：76 GB

工作量：

大师满载writes and reads，并且奴隶也满载了很多reads。 查询的最大长度可能约为8-10 secs.

我们之前尝试过的：

• Set max_standby_archive_delay and max_standby_streaming_delay to 900000（900 秒），但是我们看到很多conflict errors.

• Set max_standby_archive_delay and max_standby_streaming_delay to -1，这使得冲突错误消失，但是滞后增加了很多（在某个地方23mins)

• Set max_standby_archive_delay and max_standby_streaming_delay to -1 and hot_standby_feedback to on。这也使得冲突错误消失，但是我们仍然看到复制滞后（大约500 secs)

用于滞后的查询：

SELECT
  pg_last_xlog_receive_location() receive,
  pg_last_xlog_replay_location() replay,
  (
   extract(epoch FROM now()) -
   extract(epoch FROM pg_last_xact_replay_timestamp())
  )::int lag;

在一段时间内每 1 秒测量一次的延迟图9 hours:

问题：

1. 考虑到我们的用例（从服务器被积极用于读取查询，我们如何确保没有冲突错误and合理的延迟（大约几秒）
2. 滞后是什么意思？难道Master后面只有一张桌子吗？或者这是否意味着所有其他 WAL 也正在等待应用于从属设备。
3. 如果 1. 使用配置属性无法实现，我们如何在代码中解决它（这是最不理想的，因为代码库很大并且需要大量更改）

Thanks!

你无法完全避免冲突——每一个陈述都像TRUNCATE or ALTER TABLE这需要一个ACCESS EXCLUSIVE锁会导致复制冲突。

但你可以避免由以下原因引起的复制冲突VACUUM:

• Set hot_standby_feedback = on防止 PostgreSQL 删除备用数据库上仍需要的元组。

• Set old_snapshot_threshold避免使用默认值以外的值（可能很高）真空截断.

  这种截断需要一个ACCESS EXCLUSIVE锁也可能导致冲突。

对于其余冲突，您可以选择延迟申请和取消查询。或者你改变工作量以避免ACCESS EXCLUSIVE locks.

要找出是什么阻碍了你，你必须使用pg_xlogdump在 WAL 文件上并搜索ACCESS EXCLUSIVE锁。这将使您能够找出哪个对象被锁定。要了解执行了何种操作，请检查 (VACUUM？）或之后立即（DDL？）。