使用重读从站管理热备中 Postgres 复制的冲突和滞后

Question

要求：

避免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

工作量：

Master满载writes和reads，slave也满载了很多reads。查询的最大长度可能约为8-10秒。

我们之前尝试过的：

• 设置max_standby_archive_delay和max_standby_streaming_delay对900000（900秒），但是我们看到了很多的conflict错误。

• 设置max_standby_archive_delay和max_standby_streaming_delay到-1，这使冲突错误消失，但是滞后增加了很多（在某处23mins）

• 设置max_standby_archive_delay和max_standby_streaming_delay到-1和hot_standby_feedback 到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. 鉴于我们的用例（Slave 被积极用于读取查询，我们如何确保没有冲突错误和合理的延迟（大约几秒）
2. 滞后是什么意思？这是否意味着只有一张桌子在Master后面？或者这是否意味着所有其他 WAL 也正在等待应用于 Slave。
3. 如果 1. 使用配置属性无法实现，我们如何在代码中解决它（这是最不可取的，因为代码库很大并且需要大量更改）

谢谢！

Answer 1

你不能完全避免冲突-每一个表述喜欢TRUNCATE或ALTER TABLE需要的ACCESS EXCLUSIVE锁会导致复制冲突。

但是您可以避免由VACUUM以下原因引起的复制冲突：

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

• 设置old_snapshot_threshold为默认值以外的（可能较高）值以避免真空截断。

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

对于剩余的冲突，您可以选择延迟申请和取消查询。或者您更改工作负载以避免ACCESS EXCLUSIVE锁定。

要找出阻止您的原因，您必须使用pg_xlogdumpWAL 文件并搜索ACCESS EXCLUSIVE锁。这将使您能够确定哪个对象被锁定。要找出执行的操作类型，请检查紧接之前 ( VACUUM?) 或紧接其后 (DDL?)的 WAL 条目。