web-dev-qa-db-ja.com

barmanが使用するPostgresqlレプリケーションスロットのreplay_lagが長い

Walストリーミングを使用してバーマンをセットアップしましたが、ハグreplay_lagがあることに気づきました。私はそれを0に抑えたいのですが、これを行う方法がわかりません。

データベースレプリカもあり、正常に動作しています。

私はbarman 2.7とpostgresl 10.8を持っています

Postgresqlのレプリケーションステータスを確認したところ、次のことがわかりました。

select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------
pid              | 23095
usesysid         | 169593
usename          | repmgr
application_name | replication_server
client_addr      | xxx.16.2.66
client_hostname  | replica_server
client_port      | 51164
backend_start    | 2019-07-05 23:03:03.194165-05
backend_xmin     |
state            | streaming
sent_lsn         | 22/30884870
write_lsn        | 22/30884870
flush_lsn        | 22/30884870
replay_lsn       | 22/30884870
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async
-[ RECORD 2 ]----+------------------------------
pid              | 6689
usesysid         | 66019
usename          | streaming_barman
application_name | barman_receive_wal
client_addr      | xxx.172.16.109
client_hostname  | barman_server
client_port      | 40680
backend_start    | 2019-07-16 00:00:06.903489-05
backend_xmin     |
state            | streaming
sent_lsn         | 22/30884870
write_lsn        | 22/30884870
flush_lsn        | 22/30000000
replay_lsn       |
write_lag        | 00:00:03.01204
flush_lag        | 00:00:01.085313
replay_lag       | 583:31:21.110173
sync_priority    | 0
sync_state       | async

select * from pg_replication_slots;

-[ RECORD 1 ]-------+----------------
slot_name           | barman_slot
plugin              |
slot_type           | physical
datoid              |
database            |
temporary           | f
active              | t
active_pid          | 6689
xmin                |
catalog_xmin        |
restart_lsn         | 22/30000000
confirmed_flush_lsn |

バーマンステータスmaster_server

Server master_server:
        Description: master_server - streaming
        Active: True
        Disabled: False
        PostgreSQL version: 10.8
        Cluster state: in production
        pgespresso extension: Not available
        Current data size: 11.4 GiB
        PostgreSQL Data directory: /var/lib/postgresql/10/main
        Current WAL segment: 000000010000002200000030
        PostgreSQL 'archive_command' setting: barman-wal-archive barman_server master_server %p
        Last archived WAL: 00000001000000220000002F, at Fri Aug  9 06:56:05 2019
        Failures of WAL archiver: 63 (000000010000001C00000062 at Mon Jul 15 23:59:21 2019)
        Server WAL archiving rate: 2.60/hour
        Passive node: False
        Retention policies: enforced (mode: auto, retention: RECOVERY WINDOW OF 1 MONTHS, WAL retention: MAIN)
        No. of available backups: 1
        First available backup: 20190809T063454
        Last available backup: 20190809T063454
        Minimum redundancy requirements: satisfied (1/1)

これを修正する方法を理解するためにチェックできるリソースを誰かが私に指摘できますかWALアーカイバの障害とreplay_lag？

前もって感謝します

postgresqlbarman
1
ERQ14

pg_stat_replicationのこの大きな再生ラグは、pg_receivewalプロセスに属しているようです。現在、pg_receivewalはWALファイルのコピーを書き込みますが、どこにも適用しません。したがって、WALが適用されたことをプライマリサーバーに報告しません。

これは完全に正常です。比較 commit fd7d387e05 。

「WALアーカイバの障害」も心配する必要はありません。この数値はおそらくpg_stat_archiverから取得され、過去にWALのアーカイブに問題があったことを示しています。 「最後にアーカイブされたWAL」はより新しいWALファイルが正常にアーカイブされたことを示しているため、この問題は解決されているはずです。

PostgreSQLはアーカイブWALをスキップしません—アーカイブが失敗した場合、アーカイバはその場所で動かなくなり、成功するまで再試行します。

2
Laurenz Albe