web-dev-qa-db-ja.com

Postgres 9.3のマスター/スレーブ間の大きな遅延ラグ

この構成のPostgres 9.3データベースサーバーがあります。

# grep archive_ postgresql.conf
archive_mode = on            # allows archiving to be done
archive_command = 'rsync -a %p postgres@backupserver:9.3/standby/archive/%f'            # command to use to archive a logfile segment                                                                                                                      
archive_timeout = 300            # force a logfile segment switch after this

ホットスタンバイモードで続く別のサーバー。

WALパケットがいっぱいになるか、5分（300秒）になったときに送信されることを期待しています。

このクエリをホットスタンバイで実行すると、次のようになります。

SELECT CASE
WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location() THEN 0
ELSE EXTRACT (Epoch FROM now() - pg_last_xact_replay_timestamp())
END

次に、約1500秒の平均値を取得します。これは、構成された300秒の約5倍です。

どうして？

トラフィックの多い他のサーバーでは、遅延はわずかです。

関連質問：- PostgreSQLはいつwalファイルをアーカイブするためにarchive_commandを実行しますか？

postgresqlpostgresql-9.3recovery
1
david.perez

トラフィックの多い他のサーバーでは、遅延はわずかです。

このステートメントでは、thisサーバーには大量のトラフィックがないと想定しています。

再生するトランザクションがない場合、pg_last_xact_replay_timestamp()の値は、単に時間の経過が原因で進むことはありません。また、archive_timeoutは、アーカイブするものがある場合にのみ起動します。最後のアーカイブ切り替え以降に新しいWALデータがない場合、既存のWALファイル（最初のヘッダー以外は空）は、5分が経過しただけではアーカイブされません。

可能な回避策は、checkpoint_timeoutも300秒に設定することです。この設定の9.3では、チェックポイントはアーカイブするレコードを作成し、アーカイブはチェックポイントする作業を作成するため、アイドルサーバーで5分ごとにほぼ空のファイルを生成します。ほとんどの人はこれをバグだと考えていますが、おそらくそれはあなたのための機能です。

1
jjanes