<div dir="ltr"><div>Hi guys</div><div><br></div><div>My brain get broken. It looks like I cannot handle the issue without your hint. <br></div><div>In my case Pgpool provides incorrect data on 'show pool_nodes':<br><br><span style="font-family:monospace">[root@pg-mgrdb1 ~]# psql -U fabrix -w -h 10.65.188.59 -p 9999 postgres -c 'show pool_nodes'<br> node_id |   hostname   | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay | replication_state | replication_sync_state | last_status_change<br>---------+--------------+------+--------+-----------+---------+------------+-------------------+-------------------+-------------------+------------------------+---------------------<br> 0       | 10.65.188.55 | 5432 | up     | 0.500000  | primary | 5638095    | true              | 0                 | streaming         | async                  | 2025-01-23 16:02:22<br> 1       | 10.65.188.56 | 5432 | up     | 0.500000  | standby | 213106     | false             | 0                 |                   |                        | 2025-01-23 16:02:23<br>(2 rows)<br><br>[root@pg-mgrdb1 ~]#<br></span></div><div><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Actually, both backends are not in recovery (treated as primary), and respectively there is no replication between the nodes. Obviously, my failover/failback scripts work incorrectly, and bring the whole cluster to broken state. <br></div><div>But why pool_nodes report doesn't match to the reality? The only point that shows that something is wrong is that the <span style="font-family:monospace">replication_state</span> and <span style="font-family:monospace">replication_sync_state </span>data (streaming, async) are shown in wrong line <br>it should be printed out for standby node.The streaming check is enabled. sr_check_period set to 1. <br></div><div>It looks like something goes wrong with autofailback. In the pgpool logs I see this piece:<br><br><span style="font-family:monospace">2025-01-23 16:02:23: pid 1135: LOG:  watchdog is informed of failover start by the main process<br>2025-01-23 16:02:23: pid 1128: LOG:  starting fail back. reconnect host 10.65.188.56(5432)<br>2025-01-23 16:02:23: pid 1128: LOG:  Node 0 is not down (status: 2)<br>2025-01-23 16:02:23: pid 1128: LOG:  execute command: /etc/pgpool-II/recovery/failback_node.sh 1 10.65.188.56 5432<br>+ NODE_ID=1<br>+ NODE_HOST=10.65.188.56<br>+ NODE_PORT=5432<br>+ LOG_FILE=/home/postgres/pg_logs/failback.log<br>++ date<br>+ echo 'Thu Jan 23 16:02:23 IST 2025: Failback triggered for node 1 at <a href="http://10.65.188.56:5432">10.65.188.56:5432</a>'<br>+ true<br>+ '[' 0 -eq 0 ']'<br>++ date<br>+ echo 'Thu Jan 23 16:02:23 IST 2025: Node 1 successfully reattached.'<br>2025-01-23 16:02:23: pid 1128: LOG:  Do not restart children because we are failing back node id 1 host: 10.65.188.56 port: 5432 and we are in streaming replication mode and not all backends were down<br>2025-01-23 16:02:23: pid 1128: LOG:  find_primary_node_repeatedly: follow primary is ongoing. return current primary: 0<br>2025-01-23 16:02:23: pid 1128: LOG:  failover: set new primary node: 0<br>2025-01-23 16:02:23: pid 1128: LOG:  failover: set new main node: 0<br>2025-01-23 16:02:23: pid 1135: LOG:  received the failover indication from Pgpool-II on IPC interface<br>2025-01-23 16:02:23: pid 1135: LOG:  watchdog is informed of failover end by the main process<br>2025-01-23 16:02:23: pid 19776: LOG:  worker process received restart request<br>2025-01-23 16:02:23: pid 1128: LOG:  failback done. reconnect host 10.65.188.56(5432)<br>2025-01-23 16:02:23: pid 19780: LOG:  selecting backend connection<br>2025-01-23 16:02:23: pid 19780: DETAIL:  failover or failback event detected, discarding existing connections<br></span></div><div><br></div><div>Here is mentioned that "follow primary is ongoing". But last call for follow_primary.sh was pretty long time ago, so...<br><br></div><div>Actually, I have here two questions:<br></div><div>1) Why pgpool provide incorrect states of the backends?<br></div><div>2) What is wrong with follow_primary procedure? Is there a sense to use follow_primary for two nodes? <br></div><div><br>My pgpool.conf, failback/failover scripts and log are available for 5 days here: <a href="https://filebin.net/076qbpqicx3rffik">https://filebin.net/076qbpqicx3rffik</a> <br></div><div>I'd be highly appreciated to any advice. <br></div><div><br></div><div>BR</div><div>Igor Yurchenko<br></div></div></div></div></div>