对Postgresql来说相当陌生，但必须设置复制。我决定使用BDR，在本地的演示中运行得很好，但是在分布式机器上，它开始出现问题，主要是因为我不知道自己在做什么，我哭着为MySQL而失眠。我几乎让BDR在多个服务器上运行。当我跑步时：
SELECT bdr.bdr_node_join_wait_for_ready();
它挂在连接节点上。这在DB2和DB3上都会发生。DB1返回有效的响应。研究这个我遇到了bdr_init_copy命令，它显然做了我一直在做的每件事，然后一些。所以试过了。现在，当我跑步时：
/usr/lib/postgresql/9.4/bin/bdr_init_copy -d "host=192.168.1.10 dbname=demo3" --local-dbname="host=192.168.1.23 dbname=demo3" -n db2 -D bdr_data
我明白了
bdr_init_copy: starting ...
Getting remote server identification ...
Detected 2 BDR database(s) on remote server
Updating BDR configuration on the remote node:
demo2: creating replication slot ...
demo2: creating node entry for local node ...
demo3: creating replication slot ...
demo3: creating node entry for local node ...
Creating base backup of the remote node...
63655/63655 kB (100%), 1/1 tablespace
Creating restore point on remote node ...
Bringing local node to the restore point ...
它就在那里。我认为这两个问题的原因是一样的。据我所知，在本地节点（db2）上没有创建日志条目，但在远程节点（db1）上有以下内容
2016-10-12 22:38:43 UTC [20808-1] postgres@demo2 LOG: logical decoding found consistent point at 0/5001F00
2016-10-12 22:38:43 UTC [20808-2] postgres@demo2 DETAIL: There are no running transactions.
2016-10-12 22:38:43 UTC [20808-3] postgres@demo2 STATEMENT: SELECT pg_create_logical_replication_slot('bdr_17163_6340711416785871202_2_17163__', 'bdr');
2016-10-12 22:38:43 UTC [20811-1] postgres@demo3 LOG: logical decoding found consistent point at 0/5002090
2016-10-12 22:38:43 UTC [20811-2] postgres@demo3 DETAIL: There are no running transactions.
2016-10-12 22:38:43 UTC [20811-3] postgres@demo3 STATEMENT: SELECT pg_create_logical_replication_slot('bdr_17939_6340711416785871202_2_17939__', 'bdr');
2016-10-12 22:38:44 UTC [20812-1] postgres@demo3 LOG: restore point "bdr_6340711416785871202" created at 0/50022A8
2016-10-12 22:38:44 UTC [20812-2] postgres@demo3 STATEMENT: SELECT pg_create_restore_point('bdr_6340711416785871202')
有什么帮助吗？
最佳答案
对，只是有这个问题，其他论坛都没有帮助。其中一些节点甚至说，新节点可以将其状态报告为“o”，其他节点将新服务器状态报告为“i”，因为“这只是一个bug，很好”。这不好。新服务器可以接收复制更新，但新服务器上不可能有主更新。解决这个问题的关键是在您要加入的服务器（而不是新服务器）上启动日志记录。在新的服务器日志中，您可能会看到类似这样的内容：08006: could not receive data from client: Connection reset by peer，这不是很有帮助，并且会让您检查防火墙等。当源服务器日志中有类似：no free replication state could be found for 11, increase max_replication_slots的日志时，真正的资金来源可能是您的群集中的服务器太多，无法使用默认设置，或者，更有可能的是，有一些旧东道主留下的垃圾。
你需要清理一下。。。在现有群集中的每个服务器上（NB！）首先，在现有的集群中获取一个列表：
select * from bdr.bdr_nodes order by node_sysid;
然后，检查以下各项：
select conn_sysid,conn_dboid from bdr.bdr_connections order by conn_sysid;
.. 如果您看到旧条目（不包含第一个查询中的node\u sysid），请删除
例如
delete from bdr.bdr_connections where conn_sysid='<from-first-query>';select * from pg_replication_slots order by slot_name;
.. 如果看到不包含活动sysid的旧条目，请删除
.. 注意，使用函数，不要执行“删除自”
例如
select pg_drop_replication_slot('bdr_17213_6574566740899221664_1_17213__');select * from pg_replication_identifier order by riname;
.. 如果看到不包含活动sysid的旧条目，请删除
.. 注意，使用函数，不要执行“删除自”
select pg_replication_identifier_drop('bdr_6443767151306784833_1_17210_17213_');
幸运的是，在每个节点上完成此操作后，您将看到新服务器的BDR状态变为“r”。清理每个主机时，您应该注意到日志“08006:无法从客户端接收数据：通过对等端重置连接”，与刚刚清理的服务器的conn sysid匹配，停止发生。祝你好运