来自 kafka-connect 的 Postgres 复制槽已满答案

【问题标题】：Postgres replication slot from kafka-connect is filling up来自 kafka-connect 的 Postgres 复制槽已满
【发布时间】：2020-06-27 20:37:18
【问题描述】：

由 kafka-connector 连接器创建的复制槽正在填满。

我在 AWS 上有一个 postgres RDS 数据库。我在上面放了以下参数组选项（仅显示与默认值的差异）

rds.logical_replication: 1

我使用 debezium postgres 连接器运行 kafka 连接。这是配置（当然，某些值已编辑）

"database.dbname"        = "mydb"
"database.hostname"      = "myhostname"
"database.password"      = "mypass"
"database.port"          = "myport"
"database.server.name"   = "postgres"
"database.user"          = "myuser"
"database.whitelist"     = "my_database"
"include.schema.changes" = "false"
"plugin.name"            = "wal2json_streaming"
"slot.name"              = "my_slotname"
"snapshot.mode"          = "never"
"table.whitelist"        = "public.mytable"
"tombstones.on.delete"   = "false"
"transforms"             = "key"
"transforms.key.field"   = "id"
"transforms.key.type"    = "org.apache.kafka.connect.transforms.ExtractField$Key"

如果我得到此连接器的状态，它似乎没问题。

curl -s http://my.kafkaconnect.url:kc_port/connectors/my-connector/status | jq

{
  "name": "my-connector",
  "connector": {
    "state": "RUNNING",
    "worker_id": "some_ip"
  },
  "tasks": [
    {
      "id": 0,
      "state": "RUNNING",
      "worker_id": "some_ip"
    }
  ],
  "type": "source"
}

但是，postgres 中的复制槽越来越大：

SELECT slot_name,
  pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) as replicationSlotLag,
  pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) as confirmedLag,
  active
FROM pg_replication_slots;
           slot_name           | replicationslotlag | confirmedlag | active
-------------------------------+--------------------+--------------+--------
 my_slotname                   | 20 GB              | 20 GB        | t

为什么复制不断增长？据我了解，正在运行的 kafka 连接连接器任务应该从这个复制槽读取，将其发布到主题postgres. public.mytable，然后复制槽的大小应该减小。我在这一系列动作中遗漏了什么吗？

【问题讨论】：

标签： postgresql apache-kafka apache-kafka-connect debezium

【解决方案1】：

请看WAL Diskspace Consumption。

PostgreSQL WAL 积压的最常见原因是，连接器正在监视数据库或数据库中的表子集，与环境中的其他表或数据库相比，更改的频率要低得多，因此连接器没有确认LSN 的频率足以避免 WAL 积压。

对于 Debezium 1.0.x 及之前版本，启用heartbeat.interval.ms。
对于 Debezium 1.1.0 及更高版本，还可以考虑启用heartbeat.action.query。

【讨论】：

我会将此标记为答案，因为它通常是答案。对于 Debezium 1.0，心跳实际上并没有提交 LSN，因此复制延迟仍在增长。对于 1.1，查询会很好，但我们使用的是 ExtractField SMT，它与任何心跳都不兼容（因此它在 1.0 中也不起作用）。在这里追踪issues.redhat.com/browse/DBZ-1909
来自链接文档的重要信息："For users on AWS RDS with Postgres, a similar situation to the third cause may occur on an idle environment, since AWS RDS makes writes to its own system tables not visible to the useres on a frequent basis (5 minutes). Again regularly emitting events will solve the problem."
您如何看待将max_slot_wal_keep_size 设置为预防措施？虽然这在极端情况下可能会导致 Debezium 的数据丢失，但它也确保了 Debezium 不会关闭整个数据库！

【解决方案2】：

找到了这个google group discussion，Gunnar 提到了这个 -

core heartbeat feature 定期向心跳主题发送消息，允许确认已处理的 WAL 偏移量，以防仅发生过滤表中的事件（这是您观察到的）。 Heartbeat action queries（需要表并包含在发布中）对于解决具有多个数据库的情况很有用，其中连接器从一个数据库接收更改，否则没有/低流量，在这种情况下再次允许确认偏移量。

- 贡纳尔

在小组讨论中，他提到我们必须将此心跳表添加到发布中才能使该心跳查询起作用。这应该会有所帮助。

【讨论】：

编辑：更新：将心跳表添加到发布中。没有任何区别。此问题仍未解决。