1

我成功地在 2 个 PG 11 云虚拟机之间使用逻辑复制来获取最新数据。但我也尝试发布一些旧表以在数据库之间传输数据，并收到关于缺少 WAL 段的奇怪错误。

这些较旧的分区包含 5-6 天前的数据。我成功地将它们发布在主服务器上，并在逻辑副本上刷新了订阅。但现在我在逻辑副本上收到这些奇怪的错误消息：

2019-01-21 15:03:14.713 UTC [17203] LOG:  logical replication table synchronization worker for subscription "mysubscription", table "mytable_20190115" has finished
2019-01-21 15:03:19.768 UTC [18877] LOG:  logical replication apply worker for subscription "mysubscription" has started
2019-01-21 15:03:19.797 UTC [18877] ERROR:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000098E000000CB has already been removed
2019-01-21 15:03:19.799 UTC [29534] LOG:  background worker "logical replication worker" (PID 18877) exited with exit code 1
2019-01-21 15:03:24.806 UTC [18910] LOG:  logical replication apply worker for subscription "mysubscription" has started
2019-01-21 15:03:24.824 UTC [18911] LOG:  logical replication table synchronization worker for subscription "mysubscription", table "mytable_20190116" has started
2019-01-21 15:03:24.831 UTC [18910] ERROR:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000098E000000CB has already been removed
2019-01-21 15:03:24.834 UTC [29534] LOG:  background worker "logical replication worker" (PID 18910) exited with exit code 1

这让我很困惑。我试图找到一些信息，但没有找到任何关于根据 WAL 段进行逻辑复制的信息。

该特定主服务器上没有运行流复制，并且我在仅与逻辑复制连接的主服务器和副本上看到这些错误消息。

难道我做错了什么？是否有一些特殊的方法可以发布旧数据？对于较新的数据和最新数据，所有工作都没有问题。

当然，由于我发布了大约 20 个表，因此副本需要一些时间来处理所有表 - 目前它一次总是处理 2 个。但我仍然不明白为什么它应该依赖于 WAL 段......非常感谢。

更新：我尝试取消发布和取消订阅这些旧表并再次发布和订阅它们，但对于完全相同的 WAL 段号仍然得到相同的错误消息。

更新 2：我取消发布和取消订阅那些有问题的表并且错误消息停止，因此它们肯定与逻辑复制有关。它们可能是由快照引起的吗？

更新 3：我刚刚对 WAL 段错误产生了额外的奇怪体验——我的逻辑副本只有很小的磁盘，在所有这些摆弄过程中我忘了检查磁盘使用情况。因此逻辑副本上的 postgresql 由于磁盘已满而崩溃。由于我使用 GCE，我只是调整了根磁盘的大小，并且在实例重新启动后获得了更多空间。但我也找回了与逻辑复制连接时丢失的 WAL 段错误。我的 postgresql 登录副本现在充满了这 3 行的序列：

2019-01-22 09:47:14.408 UTC [1946] LOG:  logical replication apply worker for subscription "mysubscription" has started
2019-01-22 09:47:14.429 UTC [1946] ERROR:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000099D0000007A has already been removed
2019-01-22 09:47:14.431 UTC [737] LOG:  background worker "logical replication worker" (PID 1946) exited with exit code 1

为什么逻辑复制依赖于 WAL 段？

4

1 回答 1

1

因此，感谢 pgsql-general 邮件列表上的聪明人，我发现了问题所在。

  1. 逻辑复制实际上取决于 WAL 段 - https://www.postgresql.org/docs/11/logical-replication-architecture.html - 使用 WAL 段分发更改 - 这就是为什么参数“wal_level”必须设置为“逻辑“在主人身上。

  2. 我对 WAL 段的问题是这些情况的组合：

    • 我试图一起发布和订阅我们所有的大表——为了解释，我们每天有 5 亿条记录，最大的表每天有大约 30 GB 的分区，其他的 1 - 5 GB
    • 在这种情况下，PostgreSQL 会创建快照，并在订阅激活后开始将数据从快照传输到副本。只有在整个快照被传输之后，walsender 才会开始发送 WAL 日志以获取最新更改
    • 由于我一次发布了几天的 200 GB 数据，您可以想象传输花费了很长时间 - 为传输创建了 2 个新的逻辑复制槽，并使用 2 个 walsender 将数据传输到副本。
    • 它通常会运行良好，但我们有紧急 cronjob，它会删除太过时的 WAL 日志，因为过去我们遇到了几乎满磁盘的问题。这就是我遇到的问题 - 紧急 cronjob 删除了尚未转移到副本的 WAL 段。因此，通常需要有足够的磁盘空间来存储比正常情况更多的 WAL 日志。这是我们以前没有的——但我改变了它。

  3. 来自 pgsql-general 的 Jeremy Finzel 建议我实际上应该使用不同的方式从 master 复制数据——一次只发布和订阅一个表，并给副本时间来同步数据。我做了，现在逻辑复制就像一个魅力......

于 2019-01-23T16:28:29.590 回答