Pgpool-II + PostgreSQL 8.4を3つのサーバー(primary + standby1 + standby2)で使用しています。レプリケーションモードは「オン」ですロードバランスモードは「オン」です(プライマリとスタンバイ1の間)
私はPITRを使用してオンライン回復を構成するための公式チュートリアルを実行しました: http://pgpool.projects.postgresql.org/pgpool-II/doc/pgpool-en.html#online-recovery
スクリプト「copy-base-backup」にtarコマンドがあります。
tar -C/data -zcf pgsql.tar.gz pgsql
したがって、スクリプトの実行中にコピーされているすべてのPGクラスターディレクトリ:
ls -1 /srv/pg/data/
PG_VERSION
archive # directory with postgres archive files
backup_label.old
base
global
pg_clog
pg_hba.conf
pg_ident.conf
pg_log
pg_multixact
pg_stat_tmp
pg_subtrans
pg_tblspc
pg_twophase
pg_xlog
pgpool_recovery
pgpool_recovery_pitr
pgpool_remote_start
postgresql.conf
postmaster.opts
postmaster.pid
recovery.conf
recovery.done
プライマリノードとスタンバイノードから古いアーカイブログを安全に削除するにはどうすればよいですか?私のノードには1日あたり約30Gbのアーカイブがあります。
Pgpoolに同梱されているPITRリカバリーに関するドキュメントは本当に不完全であり、実際には誤解を招く点があります。 scpを使用してそこから各スタンバイにコピーするrecovery_commandを使用するよりも、マスター上にすべてのアーカイブファイルを保持することをお勧めします。それは無価値です。各スタンバイには、アーカイブの独自のコピーが必要です。そうでない場合、実際の冗長性はありません。その状況でマスターに障害が発生した場合、何も役に立ちません。マスターのarchive_commandは、代わりにスタンバイシステムにファイルを配布する必要があります。アーカイブのコピーをマスターに保存する必要はまったくありません。
各スタンバイでアーカイブをクリーンアップする場合、recovery_commandに対する推奨事項が不十分であるため、従うべきではありません。代わりに pg_standby をリカバリコマンドとして呼び出す必要があります。詳細は ウォームスタンバイサーバー の実際のドキュメントを参照してください。 pg_standbyを使用している場合、渡される必要があるものの1つは「%r」パラメーターです。これは、古いアーカイブログを削除するために必要な情報です。 pg_standbyをそのように使用すると、アーカイブがクリーンアップされます。
ここで重要な重要な部分は、両方のスタンバイサーバーにデータを適切にコピーするarchive_commandスクリプトを記述することです。私が指摘する良い例はありませんが、各コピーの後にエラーを確認し、両方のコピーが発生した場合にのみ成功のリターンコードを提供する必要があります。
はい、その時点で、アーカイブしたログを安全に削除できます。ただし、少し注意してください。まだアーカイブされていないログを削除したくない!