问题标签 [postgresql-bdr]

我已在不同区域的三个 AWS 节点中安装了 2nd Quadrant PostgreSQL BDR 版本 1.0.2-2017-10-31- 以进行主动-主动复制。当我在一个节点的数据库中导入数据时，复制工作正常，它复制到另一个节点。

但是，在 BDR 组的数据库中发布任何 DDL 时，它会显示错误：

错误：数据库被另一个节点锁定到 ddl
提示：集群中的节点 (6489370455887834827,1,16387) 已经在执行 DDL

尽管没有应用程序指向数据库，也没有任何活动在其上执行。

请帮忙。

问候 Debasish

遵循文档中的所有步骤，直到下面的命令被击中。

sudo yum install postgresql-bdr94-bdr

它返回错误消息“NO package postgresql-bdr94-bdr available”

我目前遇到一个关于 BDR'd postgres 数据库的问题。具体来说，一个 bdr 集群中允许的最大数据库数量。根据日志，我需要增加 bdr.max_databases 持有的值

运行postgres=# ALTER SYSTEM SET bdr.max_databases = '64';似乎失败了： ERROR: unrecognized configuration parameter "bdr.max_databases"

我找不到关于这个变量的任何文档，所以我有点迷茫。

有没有办法设置 bdr.max_databases 的值？

Postgre 版本：（PostgreSQL）9.4.14

原始错误：

我对 PostgreSQL BDR 感到困惑，我有几个问题：

问题 1：BDR 真的是 PostgreSQL 的多主机吗？

根据此处的文档，它说：

BDR（双向复制）项目在 PostgreSQL 9.4 中增加了多主复制

但如果我在 2ndQuadrant 上阅读，我会阅读以下内容：

如果我读了那部分，他们根本没有提到多主控。只是“二主，被动工作”，就说明它不是真正的主？

问题 2：BDR 是开源的吗？

我在这里读到它是，至少它是：

BDR 是 PostgreSQL 的第一个开源多主复制系统

还在吗？因为当我查看时，我经常被引导到 2ndQuadrants 网页，这给我的印象是它不是开源的，当他们说：

你如何获得 Postgres-BDR？

只需填写下面的联系表，PostgreSQL 专家将很快与您联系！

听起来像卖给我=）

问题3：什么版本是什么？

我读到 2ndQuadrant在今年 3 月发布了 1.0.5 版。我还在2ndQuadrants 网页上看到

在复制的复杂环境下，第3代BDR实现...

第三代？版本 1.0.5 是相同的第 3 代，还是其他版本？

此外，同一页面说：

当前 Postgres-BDR 用户注意事项：BDR 1.x 将于 2019 年 12 月达到 EOL。我们的 PostgreSQL 专家团队可以帮助您规划和执行升级，影响最小，停机时间几乎为零。立即联系我们，我们的专业服务团队成员将尽快与您联系。

那么，1.0.5 是在 3 月发布的，但在 2019 年 12 月就已经 EOL 了？2.x 不是开源的，所以会产生一些与之相关的许可成本，而 1.x 是 EOL 2019？

首先请让我介绍一下我的用例：我正在开发 Django 应用程序（使用 Graphene 的 GraphQL API），它在云中运行，但在本地客户的网络中也有本地实例。

例如，云中的一个应用程序和本地网络上的 3 个实例（具有启用 BDR 的 PostgreSQL 服务器的本地 Django 应用程序实例）。如果有网络连接，我们将使用双向复制来获取新数据，因为如果没有连接，我们将使用本地实例。这是用于说明的简化基础架构图。

所以，如果我想使用 BDR，我不能在 ORM 中执行 DELETE 和 UPDATE 操作。我必须为我的实体生成 UUID，每次更改都只是一条新记录，其中包含相同 UUID 的更新数据。所选 UUID 的最新记录是我的有效记录。删除只是另一个标志。到目前为止，一切似乎都很好，当我想使用例如多对多关系时问题就开始了。关系依赖于数据库主键，我必须以某种方式处理删除。您能找到解决此问题的最佳方法吗？我没有什么想法，但我不想做出错误的决定：

1. 我可以尝试覆盖 ManyToManyField 以使用我的 UUID 和特殊删除标志。这看起来是个好主意，因为一切都应该像以前一样工作（石墨烯会找到关系等）。但我害怕“看不见”的后果。
2. 创建我自己的模型来模拟多对多关系。这是更多的工作，但它应该工作得很好。

您以前是否必须解决类似的问题？是否有某种好的做法，或者它只是在建造一条通往地狱的高速公路（AC/DC 非常酷）？

或者，如果您认为有更好的方法来构建服务架构，我很想听听您的想法。

提前致谢。

如果可以的话，我想在添加更多细节之前写一个问题的简短摘要，以使我的问题更清晰：

我有一个 BDR 组在生产中运行，复制在所有节点中都可以正常工作，但是我在其中一个节点中遇到了关于复制槽的错误，我想在不破坏其他任何东西的情况下修复这些错误......

更多细节：

我有一个在 PostgreSQL 9.4 上运行的三节点 BDR 组，2 个节点使用 RedHat7，另一个使用 Centos7。数据库名称是“MCT”。

从任何节点到其他节点的复制都运行良好，但是......

所有节点都在其日志中显示复制槽问题：

REDHAT_1：

REDHAT_2：

CENTOS_1：

如果我运行此查询：

我得到这个结果：

REDHAT_1：

REDHAT_2：

CENTOS_1：

这个查询：

REDHAT_1：

REDHAT_2：

CENTOS_1：

因此，我想知道如何在不破坏当前正在生产的 BDR 中的任何内容的情况下摆脱该错误。

有什么想法吗？

先感谢您！