对 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”,因为“这只是一个错误,没关系”。这不好。新服务器可以接收复制更新,但新服务器上不可能进行主更新。解决此问题的关键是在您要加入的服务器(不是新服务器)上启动日志记录。在新的服务器日志上,您可能会看到类似:08006: could not receive data from client: Connection reset by peer
的内容,这不是很有帮助,并且会让您检查防火墙等。当源服务器日志中有类似以下内容的日志时,真正赚钱的将来自源服务器日志:no free replication state could be found for 11, increase max_replication_slots
什么是可能发生的情况是,对于默认设置,您的集群中的服务器过多,或者更有可能是旧主机留下了一些垃圾。
您需要清理现有集群中每台服务器上的东西(注意!)。首先获取现有集群上的事物列表:
select * from bdr.bdr_nodes order by node_sysid;
然后,检查以下内容:
select conn_sysid,conn_dboid from bdr.bdr_connections order by conn_sysid;
.. 如果您看到旧条目(不包含第一个查询中的 node_sysid),则删除 例如。 ojit_代码
select * from pg_replication_slots order by slot_name;
.. 如果您看到不包含事件 sysid 的旧条目,请删除 .. 注意,使用函数,不要做“删除” 例如。 ojit_代码
select * from pg_replication_identifier order by riname;
.. 如果您看到不包含事件 sysid 的旧条目,请删除 .. 注意,使用函数,不要做“从”中删除
select pg_replication_identifier_drop('bdr_6443767151306784833_1_17210_17213_');
运气好的话,在每个节点上完成此操作后,您会看到新服务器的 BDR 状态变为“r”。当您清理每个主机时,您应该注意到日志“08006:无法从客户端接收数据:连接被对等方重置”,与您刚刚清理的服务器的 conn-sysid 匹配,停止发生。祝你好运
关于postgresql - bdr_init_copy 无限期挂起,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40009570/