问题标签 [logical-replication]

我正在尝试使用 Debian 9 和 PG 11.1 在 2 个云实例之间设置逻辑复制。master 上的命令CREATE PUBLICATION成功，但是当我CREATE SUBSCRIPTION在预期的逻辑副本上启动命令时，命令无限期挂起。

在主服务器上，我可以看到复制槽已创建并处于活动状态，我可以看到一个新的 walsender 进程已创建并“等待”，在主服务器的日志中，我看到这些行：

但仅此而已。命令CREATE SUBSCRIPTION永远不会结束。

Master 是一个带有大量插入的数据库，例如每分钟 100 次，但它们总是被提交。所以不应该有任何长时间未提交的事务。

我试图用谷歌搜索这个问题，但没有找到任何东西。我错过了什么？

我正在测试 2 个 PostgreSQL 11 数据库之间的逻辑复制以用于我们的生产（由于这个答案，我能够设置它 - PostgreSQL logical replication - create subscription hangs）并且效果很好。

现在我正在测试可以在生产数据库上自动设置它的脚本和程序，但是我遇到了逻辑复制槽的奇怪问题。

由于设置中的一些更改需要重新启动，我不得不重新启动逻辑副本——这当然也可能在将来发生在副本上。但是 master 上的逻辑复制槽没有断开连接，并且对于某些 PID 仍然处于活动状态。

我放弃了对 master 的订阅（我仍然只是测试）并尝试使用新的逻辑复制槽重复整个过程，但我面临着奇怪的情况。

我无法使用新名称创建新的逻辑复制槽。在旧的逻辑复制槽上运行的进程仍处于活动状态并显示wait_event_type=Lock和wait_event=transaction。

当我尝试使用pg_create_logical_replication_slot创建新的逻辑复制槽时，我遇到了类似的情况。新插槽已创建 - 我在 pg_catalog 中看到它，但对于发出此命令的会话的 PID，它被标记为活动，并且命令无限期挂起。当我检查进程时，我可以看到这个命令以相同的等待值锁定/事务处于活动状态。

我试图在 postgresql.conf 中激活参数“lock_timeout”并重新加载配置，但它没有帮助。

杀死旧的挂起进程很可能会导致整个 postgres 崩溃，因为它是“walsender”进程。它在进程列表中仍然可见，副本的 IP 状态为“idle wating”。

我试图找到一些可以帮助我强制 postgres 停止这个 walsender 的参数。但是设置 wal_keep_segments 或 wal_sender_timeout 并没有改变任何东西。我什至试图停止复制更长的时间 - 没有效果。

有没有办法在不重新启动整个 postgres 的情况下解决这种情况？就像强制 walsender 超时或事务锁定等...

因为如果在生产中发生这样的事情，我将无法使用重新启动或任何其他“蛮力”。谢谢...

更新： “Walsender”进程在一段时间后“消失”，但日志没有显示任何关于它的信息，所以我不知道它到底是什么时候发生的。我只能猜测它取决于 tcp_keepalives_* 参数。Debian 9 的默认值为 2 小时以保持空闲进程。所以我尝试在 postgresql.conf 中设置这些参数，并将在以下测试中看到。

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

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

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

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

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

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

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

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

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

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

想象一下放弃订阅并从头开始重新创建它。是否可以在第一次同步期间忽略现有数据？

创建订阅(copy_data=false)不是一个选项，因为我确实想复制数据，我只是不想复制已经存在的数据。

示例：usersmaster上有一个表和一个对应的发布。该表有 100 万行，每分钟添加一个新行。然后我们放弃订阅一天。

如果我们用 重新创建订阅(copy_data=true)，由于与现有数据的冲突，复制将不会开始。如果我们指定(copy_data=false)，将丢失 1440 个新行。我们如何正确同步发布者和订阅者？

我们希望使用 Postgres 逻辑复制将更改从上游服务器（“源”服务器）移动到下游服务器（“接收器”服务器）。

当我们模拟灾难恢复场景时，我们会遇到问题。为了模拟这一点，我们在复制仍处于活动状态时删除了源数据库。然后我们启动一个新的源数据库并尝试：a）将数据从接收器移动到源，b）设置复制。在这个阶段，我们会遇到两个错误之一，具体取决于我们设置复制的时间（移动数据之前或之后）。

我们在测试上述内容后得到的错误是以下之一：

复制槽已被使用，难以重新启用槽而不删除

由于 PK 冲突，无法创建订阅

一些可能的解决方案：

• 在给定的 WAL 记录号之后设置逻辑复制。这样可以避免我们面临的PK问题
• 找到在源数据库上重新创建复制槽的方法
• 备份 Postgres 服务器，包括复制槽，然后重新导入

这是否适合 Postgres 逻辑复制的用例？这是一个典型的灾难恢复场景，所以想知道如何最好地实施。谢谢！

我正在使用 Java 进行 PG 逻辑复制，并在jdbc 驱动程序文档上找到了一个演示

然后我可以从流中解析消息。

这对于一些日常需求来说已经足够了，但是现在我想知道事务提交时间。

在stackoverflow上的问题的帮助下，我添加.withSlotOption("include-timestamp", "on")了它并且它正在工作。

我的问题是在哪里可以找到有关“插槽选项”的完整列表，因此我们可以非常方便地找到它们，而不是在 google 或 stackoverflow 上搜索。

有没有办法查看 Postgres 表具有什么样的副本标识，无论是使用 pgAdmin 还是通过查询？

我正在使用 PostgresSQL 9.6 并且有一个内省数据库的过程。我有以下错误：

我必须修改我的表格吗？有什么指导吗？

我有一个发布者和一个订阅者。我经常得到：

我可以猜到为什么它异常终止，其中一台计算机关闭。但是，当两台计算机再次连接时，它不会自动重启。

唯一可行的方法是截断订阅中的所有表，删除订阅和发布，然后再次创建订阅和发布。

我试着看看 WAL，它们非常好。不知道该怎么做。

以下是一些图片：

我正在尝试仅在一张表上的两台服务器之间运行 PostgreSQL (10.6) 逻辑复制。该表具有 Id(int2) 作为主键。这是有意的，该表充当一些 IoT 时间序列数据的滚动窗口。在主节点上写入很重。整个表有大约 10 分钟的传感器数据。这就是我们喜欢保留的设计。

Master 和 Replica 节点之间的逻辑复制运行良好，直到网络中断持续超过 1 小时。同时，主节点上的 PostgreSQL 正在收集 WAL 文件，并在表上逐步插入/更新。如此有效地，WAL 文件可能包含我们不感兴趣的甚至数小时的数据，并且当连接恢复时，它们需要永远从 Master -> Replica 逐步重播。它基本上是重放数据库表中长时间不存在的记录！

如何设置它以便仅重播相关数据？如果这很难做到，有没有办法丢弃早于 10 分钟的 WAL 文件，这样它们就不会被发送？

我尝试过使用 postgresql.conf 设置。我不确定是否有一个标志可以限制在复制槽断开连接的情况下存储的 WAL 文件。

这是表格的样子：

我想设置此类表的逻辑复制，以便在发生长时间的互联网中断时恢复速度很快并且仅包含最新数据。