web-dev-qa-db-ja.com

Postgresql9.3ホットスタンバイでのログ配布

私のセットアップ

Postgresで初めてストリーミングレプリケーションを設定しました（9.3.5）。ストリーミングが期待どおりに機能している間、すべてのログを保存できるように、スタンバイでarchive_commandを実行するのに苦労しています。ファイル。

マスターpostgres.conf：

_wal_level = hot_standby
checkpoint_segments = 8
max_wal_senders = 4
wal_keep_segments = 8
_

スタンバイpostgres.conf：

_wal_level = hot_standby
checkpoint_segments = 8
archive_mode = on
archive_command = 'test ! -f /backup/postgres_archive/constant/%f && cp %p /backup/postgres_archive/constant/%f'
max_wal_senders = 3
wal_keep_segments = 8
hot_standby = on
_

スタンバイrecovery.conf：

_standby_mode = 'on'
primary_conninfo = 'Host=my-Host.example.com port=5432 user=replicator password=my_password sslmode=require'
restore_command = 'cp /backup/postgres_archive/constant/%f %p'
trigger_file = '/tmp/postgresql.trigger'
_

書き込もうとしているフォルダーのアクセス許可は正しく、ユーザーpostgresが実行されているときに手動で実行すると、archive_commandは正常に機能します。確かに、アーカイブコマンドを簡単なタッチに変更しようとしましたが（ここでも、postgresユーザーとして正常にテストされました）、違いはありませんでした。

働いているもの

私のDBはまだ比較的初期段階にあるため、負荷はほとんどありません。この目的のために、私はランダムなデータをテストテーブルに書き込むことによってそれをシミュレートしています。マスターでコミットした後、スタンバイですぐに変更が表示されるのを確認できるので、満足しています。

私がよく理解していないことの1つは、WALファイルがスタンバイであり、マスターがわずかに異なることですが、どちらかがまだ書き込みを開始していないWALをプロビジョニングしたように見えます（そうではありません）。もう一方の）。それは正常ですか？

マスターでselect pg_switch_xlog()を実行してからさらに書き込みを行うと、マスターとスタンバイの両方が切り替わり、次の/同じWALファイルへの書き込みを開始するように見えます。これは、何が起こっているのかについての私の理解を反映しています。

助けて

これについていくつか質問があります。私はこれに関するpostgresマニュアルのすべてのページを読みましたが、私の特定のケースで役立つものは何も見つかりませんでした。

Postgresが何をしているのか、何をしていないのかについての詳細をログファイルに表示する方法を見つけようとしましたが、有用なものは何も見つかりませんでした。これをデバッグする際に、ログにできるだけ多くの有用な情報を取得するために、構成で何を変更する必要がありますか？

ログアーカイブがいつ実行されるかという点では、マスターはアクティブなWALファイルを制御しているので、ログ配布をスタンバイで実行するタイミングのトリガーとして効果的だと思います。あれは正しいですか？

ストリーミングレプリケーションはすべて期待どおりに機能しているように見えますが、スタンバイでログ配布を実行しようとしても、試行していないようです。私は何が間違っているのですか？

postgresqldatabase-replicationlog-shippingpostgresql-9.3
3
Aidan Kane

私もこの問題に遭遇しました。ここで重要なのは、実際にはスタンバイの「recovery.conf」にあるarchive_cleanup_commandです。スタンバイは、プライマリからのWALセグメントの処理が完了すると、archive_cleanup_commandコマンドを実行するため、その時点で、そのWALセグメントとそれ以前のすべてのセグメントをバックアップできることがわかります。私の「recovery.conf」には次のものがあります。

archive_cleanup_command = '/var/lib/postgresql/wal_backup_mirror.sh "%r"'

そのスクリプトの内容は次のとおりです（簡略版）：

CURRENT_WAL_FILE="$1"
for WAL_FILE in $(find /pg_logs/main -maxdepth 1 -type f | sort | awk "\$0 <= \"/pg_logs/main/${CURRENT_WAL_FILE}\""); do
  WAL_NAME=$(basename "$WAL_FILE")
  gzip -c "$WAL_FILE" > "/backups/wal/${WAL_NAME}.gz"
  #now upload the just created .gz to S3 or some other offsite storage

  rm -f "${WAL_FILE}"
done

ここで、スタンバイでログディレクトリをクリーンに保つために、バックアップ後にWALセグメントを削除することに注意してください。ただし、チェーンのさらに下流にあるスタンバイでもWALセグメントが必要になる可能性があるため、カスケードレプリケーションのセットアップに注意する必要があります。ファイル。

最後に、WALセグメントのバックアップは十分ではなく、何らかの定期的な完全バックアップ（pg_basebackup）と組み合わせて実行する必要があることに注意してください。毎日完全バックアップを実行し、必要に応じてWALセグメントを1日中バックアップします。

3
ralfthewise