问题标签 [logical-replication]

是否可以使用 PGlogical 设置从 PostgreSQL 到 Kafka 的复制？目前我们正在使用 attunity 作为我们的复制工具，这一直在我们的实例上造成问题。我们正在使用 RDS PostgreSQL。

我们正在运行一个 RDS PostgreSQL。我运行 pg_locks 来检查对象上的锁 - 有一张表始终被超级用户锁定（ RowExclusiveLock ），当我尝试从 pg_Stat_Activity 获取该会话的详细信息时，它显示了一个后台工作人员，看起来它甚至没有做任何东西，这个表是复制的一部分，这个锁会导致复制会话被阻塞。有什么线索吗？

是否可以在处于级联复制模式的备用服务器上启用逻辑复制？

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

尽管我们定期对插槽的流使用 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 获取流式更改。

我在两个 postgres 实例之间设置了几个（逻辑）复制表。所有 SELECT、INSERT、UPDATE、DELETE 事务都按预期复制。

我的用例是从逻辑转储文件（自定义格式、COPY 或 INSERT？）中恢复/附加数千行

TRUNCATE 没有被复制......据我了解（这也依赖于其他商业数据库供应商如何做到这一点的知识），因为它绕过了复制机制所需的事务日志（如果逻辑复制依赖于WAL 段？）

由于我找不到任何有关它的文档，我想知道是否：

• COPY 绕过事务日志（WAL）？
• COPY 对逻辑复制有任何限制，因此实际上在复制环境中必须使用 INSERT？

PS对不起，如果我在这里混淆了东西，我真的很想澄清这些主题，以更好地了解它们是如何协同工作的

我正在尝试使用logical-replication和docker-compose在postgres中设置一个简单的复制场景。如您所见，我正在为主数据库（发布者）使用 postgres 服务，而为副本（订阅者）使用另一个服务。使用此方法在两个服务中配置。wal_level = logical

码头工人-compose.yml：

主初始化.sql：

副本-init.sql：

postgres.conf：

当我尝试启动服务时，我收到了这个错误：

您可以在下面找到整个标准输出：

我有一个从 postgres 读取逻辑复制消息的简单过程。此过程每秒运行一次，并在 postgres 日志中生成大量消息，例如：

我已经使用以下设置配置了日志记录：

但是，仍然会产生逻辑复制日志。

是否有禁用这些消息的设置？我可以使用 sed 或类似的东西，但更喜欢内置解决方案。

在我的 DEV 服务器上，我测试了逻辑复制，然后返回到流式传输。

现在wal_level = replica我有两个奴隶：

现在我创建了新表并插入了一条记录。例如：

该表已创建并复制到两个从属服务器，但删除查询失败并出现错误：

SQL 错误 [55000]：错误：无法从表“test_delete”中删除，因为它没有副本标识并发布删除提示：要启用从表中删除，请使用 ALTER TABLE 设置 REPLICA IDENTITY。

所以，在切换逻辑复制和从表中删除的能力之前，我需要帮助来恢复状态

我从 Postgres 10.3 逻辑复制中遇到错误。

设置

• 在master中，postgresql使用12.3
• 在逻辑上，postgres 10.3

日志

我们正在尝试将我们的 postgres 数据库从一项服务迁移到另一项服务（例如从 AWS RDS 到 Google Cloud）。我们使用了 Google 的内置数据库迁移服务 (DMS)，它使用了pglogical扩展。

我们的源数据库在 postgres 9.6 中，我们开始将数据复制到另一个版本为 13 的 postgres。数据已成功复制，但由于没有primary_key约束，很少有表错过复制。如果不同步目标中的这些表，我们将无法使用目标数据库。我有以下问题，

1. 具有 primary_key 约束的表已经同步，并且最新数据也会更新到目标，因为它是连续复制。单独添加 primary_key 会将数据复制到目标还是我们需要重新启动pglocical？我问这个是因为我们无法控制pglogicalGoogle 的 DMS 处理迁移过程。

2. 我们无法从头开始重新启动，因为我们的数据库大小超过 2TB，这会消耗大量时间来复制数据。我知道我们可以手动复制这些表。还有其他更好的方法来解决这个问题吗？

重要提示：当使用 pglogical 复制进行逻辑同步时，是否建议更改架构？