它是cluster的一个子部分，我正在建设中。当我在master上执行pcp_recovery_node以使用该命令从头开始构建备用数据库时
pcp_recovery_node -h 193.185.83.119 -p 9898 -U postgres -n 1
这里，193.185.83.119是贵宾。它成功构建并启动了node-b上的备用数据库（比如节点是node-a和node-b），但同时上面的命令没有返回，只是挂在shell中，如： -
[postgres @ rollc-filesrvr1 data] $ pcp_recovery_node -h 193.185.83.119 -p 9898 -U postgres -n 1密码：
我必须使用ctrl + c来退出这个会话。稍后，当我尝试在node-a（master）上创建测试数据库时，我收到以下错误：
postgres=# create database test; ERROR: source database "template1" is being accessed by other users DETAIL: There is 1 other session using the database.
我确认pgpool.service在node-a上运行此命令时正在运行，我尝试在发出pcp命令之前在node-b（standby）上使用on / off pgpool.service。结果保持不变。
我还尝试使用google搜索和调整pgpool.conf中的设置。我不确定它是否可能是这些参数的东西：
pgpool.conf中的wd_lifecheck_dbname
最初与上面相关的设置是（我得到的结果仍然相同）：
wd_lifecheck_dbname = 'template1'
wd_lifecheck_user = 'nobody'
wd_lifecheck_password = ''
后来，我在here，here和here的一个建议中找到了不同的设置，尝试了以下不同的组合：
wd_lifecheck_dbname = 'template1'
wd_lifecheck_user = 'postgres'
wd_lifecheck_password = ''
要么
wd_lifecheck_dbname = 'postgres'
wd_lifecheck_user = 'postgres'
wd_lifecheck_password = ''
但是没有人帮助改变shell上的情况，也没有让我在master上创建测试数据库。我觉得，我走到了尽头。
我仍然无法完全理解pgpool中上述3个参数的目的和意义，并且不知何故怀疑这些是我配置不正确的，尽管也可能有其他原因。
只是为了帮助，这里再次是环境细节。
以下是来自node-a pgpool.service的日志
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 16642: LOG: forked new pcp worker, pid=8534 socket=7
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 8534: LOG: starting recovering node 1
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 8534: LOG: executing recovery
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 8534: DETAIL: starting recovery command: "SELECT pgpool_recovery('recovery_1st_stage', 'node-a-ip', '/data/test/data', '5438', 1)"
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 8534: LOG: executing recovery
Mar 18 21:10:17 node-a pgpool[16583]: 2019-03-18 21:10:17: pid 8534: DETAIL: disabling statement_timeout
Mar 18 21:10:18 node-a pgpool[16583]: 2019-03-18 21:10:18: pid 8534: LOG: node recovery, 1st stage is done
Mar 18 21:11:37 node-a pgpool[16583]: 2019-03-18 21:11:37: pid 8534: LOG: checking if postmaster is started
Mar 18 21:11:37 node-a pgpool[16583]: 2019-03-18 21:11:37: pid 8534: DETAIL: trying to connect to postmaster on hostname:node-b-ip database:postgres user:postgres (retry 0 times)
...
...2 more times
Mar 18 21:11:49 node-a pgpool[16583]: 2019-03-18 21:11:49: pid 8534: LOG: checking if postmaster is started
Mar 18 21:11:49 node-a pgpool[16583]: 2019-03-18 21:11:49: pid 8534: DETAIL: trying to connect to postmaster on hostname:node-a-ip database:template1 user:postgres (retry 0 times)
...it keeps on trying till i press ctrl+c on pcp command windows . I have seen it going upto 30 or more.
此外，在使用pgpool进行检查时，node-b永远不会显示为up。
postgres => show pool_nodes; node_id |主机名|港口|状态| lb_weight |角色| select_cnt | load_balance_node | replication_delay | last_status_change --------- + ---------------- + ------ + -------- + ------ ----- + --------- + ------------ + ------------------- + - ------------------ + --------------------- 0 | node-a-ip | 5438 | up | 0.500000 |主要| 0 |是的| 0 | 2019-03-18 22:59:19 1 | node-b-ip | 5438 |下来| 0.500000 |待机| 0 |假| 0 | 2019-03-18 22:59:19（2排）
编辑现在我至少能够纠正此查询的最后一部分。即将备用节点添加到集群：
[postgres @ node-a-hostname] $ pcp_attach_node -n 1密码：pcp_attach_node - 命令成功
现在最后一部分至少显示正确的情况：
postgres => show pool_nodes; node_id |主机名|港口|状态| lb_weight |角色| select_cnt | load_balance_node | replication_delay | last_status_change --------- + ---------------- + ------ + -------- + ------ ----- + --------- + ------------ + ------------------- + - ------------------ + --------------------- 0 | node-a-ip | 5438 | up | 0.500000 |主要| 0 |假| 0 | 2019-03-18 22:59:19 1 | node-b-ip | 5438 | up | 0.500000 |待机| 0 |是的| 0 | 2019-03-19 11:38:38（2排）
但是无法在node1上创建db的基本问题仍然存在：
EDIT2：我尝试在master上插入和更新，并且它们正确地被复制到node2但是创建db仍然无法正常工作。
对EDIT1的第一次修正：事实上，pcp_attach_node帮助纠正了show pool_nodes的输出，但它进一步使问题变得复杂，因为其他命令
pcp_watchdog_info -h 193.185.83.119 -p 9898 -U postgres
开始卡住了。后来，我发现了
pcp_attach_node -n 1
根本不需要连接待机或更正show pool_nodes的输出;在主IF上原始pcp_recovery_node正确完成。
好吧，原始问题的根本原因，以及后来发生的看门狗卡住，是pgpool_remote_start脚本即使在启动待机后也没有正确完成。我可以看到它
ps -ef |抓住了pgpool
在主人。
我联系了here的pgpool_bug_tracking系统，他们帮助我进一步修复它。 pgpool_remote_start中的postgres start命令不正确导致了麻烦，因此pcp_recover_node没有完成，之后就没有了。
pgpool_remote_start中的正确命令应该是（并且我使用它）：
ssh -T postgres@$REMOTE_HOST /usr/pgsql-10/bin/pg_ctl -w start -D /data/test/data 2>/dev/null 1>/dev/null </dev/null &
我正在使用
ssh -T postgres @ $ REMOTE_HOST / usr / pgsql-10 / bin / pg_ctl start -D / data / test / data
我失踪了-w flag。此外，没有将stdout和stderr重定向到/ dev / null并且缺少向其发送的EOF信号。
一个人仍然不清楚，但对面临类似问题的人有帮助：首先启动pgpool.service待机或继续运行，然后在master上发出pcp命令。