2

我们的 postgresql 数据库（版本 11）实例中有两个逻辑复制槽，我们使用 pgJDBC 从这两个槽中流式传输数据。我们确保当我们定期发送反馈并将两个插槽的 confirm_flush_lsn（每 10 分钟）更新到相同位置时。然而，从我们的数据中我们看到，两者的 restart_lsn 移动并不同步，并且大多数情况下，它们中的一个滞后太远而无法不必要地保存 WAL 文件。这里有一些数据点来说明问题

Thu Dec 10 05:37:13 CET 2020
                      slot_name       |  restart_lsn  | confirmed_flush_lsn 
--------------------------------------+---------------+---------------------
 db_dsn_metadata_src_private          | 48FB/F3000208 | 48FB/F3000208
 db_dsn_metadata_src_shared           | 48FB/F3000208 | 48FB/F3000208
(2 rows)



Thu Dec 10 13:53:46 CET 2020
                      slot_name      |  restart_lsn  | confirmed_flush_lsn 
-------------------------------------+---------------+---------------------
 db_dsn_metadata_src_private         | 48FC/2309B150 | 48FC/233AA1D0
 db_dsn_metadata_src_shared          | 48FC/233AA1D0 | 48FC/233AA1D0
(2 rows)


Thu Dec 10 17:13:51 CET 2020
                      slot_name      |  restart_lsn  | confirmed_flush_lsn 
-------------------------------------+---------------+---------------------
 db_dsn_metadata_src_private         | 4900/B4C3AE8  | 4900/94FDF908
 db_dsn_metadata_src_shared          | 48FD/D2F66F10 | 4900/94FDF908
(2 rows)

尽管我们定期对插槽的流使用 setFlushLsn() 和 forceStatusUpdate ，但名称为 private 的插槽仍远远落后于 confirm_flush_lsn ，名称为 shared 的插槽也落后于 confirm_flush_lsn 但不会太远。由于 restart_lsn 的移动速度不够快，导致 WAL 日志文件管理出现很多问题，并且不允许删除它们以释放磁盘空间

如何解决这个问题？是否有任何通用指南来克服这个问题？

我们已经看到另一个有类似问题的线程，但那里也没有回复。 WAL 被堆积起来 - 逻辑复制的 restart_lsn 不在 PostgreSQL 中移动

我在这里使用 pgJDBC 发布的示例程序：https://jdbc.postgresql.org/documentation/head/replication.html 从此处的 postgresql 获取流式更改。
4

0 回答 0