The index of backend node to get information of.
Display all backend nodes information.
See pcp_common_options.
Here is an example output:
$ pcp_node_info -w -p 11001 -n 1 /tmp 11003 1 0.500000 waiting up standby standby 0 streaming async 2021-02-27 14:51:30
The result is in the following order:
1. hostname 2. port number 3. status 4. load balance weight 5. status name 6. actual backend status (obtained using PQpingParams. Pgpool-II 4.3 or later) 7. backend role 8. actual backend role (obtained using pg_is_in_recovery. Pgpool-II 4.3 or later) 9. replication delay 10. replication state (taken from pg_stat_replication. Pgpool-II 4.1 or later) 11. sync replication state (taken from pg_stat_replication. Pgpool-II 4.1 or later) 12. last status change time
3 (status) is represented by a digit from [0 to 3].
0 - This state is only used during the initialization. PCP will never display it.
1 - Node is up. No connections yet.
2 - Node is up. Connections are pooled.
3 - Node is down.
4 (load balance weight) is displayed in normalized format (0 - 1).
6 shows the backend status in real time. The info is obtained by
calling PQpingParams at the time when the
command is invoked. PQpingParams is only
available in PostgreSQL 9.1 or later. If
Pgpool-II was built with
PostgreSQL 9.0 or earlier, the column
shows "unknown". Also
if health check
is disabled, it shows "unknown".
When a backend node is detached by pcp_detach_node, the status managed by
Pgpool-II will be "down", while the
actual backend status is "up". Thus it is possible that 5 does not
match with 6. However it should not happen that 5 is "up" while 6
is "down".
8 shows the backend status in real time. The result will be either
"primary" or "standby", and possibly "unknown" if information
retrieval failed. Since Pgpool-II
searches backend nodes in the node id order and assumes the last
found node is primary, it is possible that 7 does not match 8 when
there are multiple nodes that are not standby by erroneous
operations (this command is useful to find such that situation).
In other than streaming replication mode, the status will be either
"main" or "replica". Unlike streaming replication mode
pg_is_in_recovery is not called and value for
7 and 8 will be always the same.
To correctly 9, 10, 11 are displayed, sr_check_period must not be 0. 10, 11 will not be displayed if sr_check_user is not PostgreSQL super user nor it's not in "pg_monitor" group.
Note: To make sr_check_user in pg_monitor group, execute following SQL command by PostgreSQL super user (replace "sr_check_user" with the setting of sr_check_user):
GRANT pg_monitor TO sr_check_user;For PostgreSQL 9.6, there's no pg_monitor group and sr_check_user must be PostgreSQL super user.
The -a or --all option lists all backend nodes information.
$ pcp_node_info -w -p 11001 -a /tmp 11002 1 0.500000 waiting up primary primary 0 none none 2021-02-27 14:51:30 /tmp 11003 1 0.500000 waiting up standby standby 0 streaming async 2021-02-27 14:51:30
The --verbose option can help understand the output. For example:
$ pcp_node_info -w -p 11001 --verbose 1 Hostname : /tmp Port : 11003 Status : 1 Weight : 0.500000 Status Name : waiting Backend Status Name : up Role : standby Backend Role : standby Replication Delay : 0 Replication State : streaming Replication Sync State : async Last Status Change : 2021-02-27 14:51:30