[pgpool-general: 8527] Re: "delay_threshold_by_time" not detecting replication lag
Tatsuo Ishii
ishii at sraoss.co.jp
Wed Dec 28 08:16:55 JST 2022
> I wrote a "capture" script that runs several commands/queries to
> demonstrate this issue
> Script uses the query you requested (except I added the entire
> replay_lag columns also)
> The script followed by the output is below and it shows:
> * when replay lag was 56+ seconds (according to pg_stat_statements),
> the output from SHOW POOL_NODES and from pcp_node_info showed no delay
> * there was no entry in the log showing replication log threshold being exceeded
>
> SCRIPT:
[snip]
> OUTPUT:
>
> [postgres at localhost]$ ./check_lag.sh
>
>
> 2022-12-27T15:18:55+00:00 | checking lag on primary directly via
> pg_stat_replication...
> application_name | state | sync_state | int4 | replay_lag
> ------------------+-----------+------------+----------+-----------------
> walreceiver | streaming | async | 56663201 | 00:00:56.663201
> (1 row)
It seems application_name is "walreceiver", which is different from
your pgpool.conf:
> backend_application_name1 = 'pg-2'
Pgpool-II checks the application name when delay_threshold_by_time >
0. If the result of pg_stat_replication.application_name does not
match, replay_lag will be ignored. Check your primary_conninfo in
postgresql.conf of the standby node to see whether application_name is
properly set.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
More information about the pgpool-general
mailing list