アーカイブされたWALファイルがどのように使用され、いつクリーンアップできるかを理解するための助けが必要です。
現在、スレーブに複製するマスターデータベースがありますが、archive_command
を使用してアーカイブしたファイルを構築し、手動で削除する必要があるため、マスターデータベースサーバーのディスク領域が不足することがよくあります。古いアーカイブされたWALファイルを手動で削除する必要がある場合、ファイルシステムのディスク領域が不足しているために何かが不足しているように感じます...
とは言っても、ファイルの削除を開始するのに十分なレプリケーションプロセスを理解できているとは限らないため、何も台無しにしていないと確信できます。スレーブはarchive_command
によって作成されたアーカイブファイルを使用しますか、それとも$PG_DATA/pg_xlog
ディレクトリ内のファイルのみに依存して、マスターとの一貫した状態を維持しますか?
その場合、マスターの ドキュメントから:pg_dump
を6時間ごとに実行している場合、pg_dump
の最初に存在するすべてのアーカイブファイルも消去するようにバックアップスクリプトを更新できますか(一度だけpg_dump
はもちろん完了しています)?
注:pg_dumpとpg_dumpallはファイルシステムレベルのバックアップを作成しないため、継続的アーカイブソリューションの一部として使用できません。このようなダンプは論理的であり、WALの再生で使用するのに十分な情報が含まれていません。
アーカイブファイルをクリーンアップしたことを確認したいだけです。レプリケーションを続行するために必要なものが残っているだけでなく、最後のベースバックアップ以降にPITRを実行できます。
アーカイブコマンドはcp %p /var/lib/postgresql/9.2/archive/%f
で、スレーブからのrecovery.conf
ファイルは次のとおりです。
standby_mode = 'on'
primary_conninfo = 'Host=<ip-address> port=<port> user=rep password=<password> sslmode=require'
trigger_file = '/tmp/postgresql.trigger.5432'
WALファイルは、行われたすべてのトランザクションの記録ですが、それだけです。基本的に、前の状態と後の状態の差分です。つまり、WALファイルを適用する前に、BASEを用意する必要があります。
新しいBASEを作成せずにWALアーカイブを消去すると、データベースから(PITRを介して)復元しようとしたときに問題が発生します。
WALファイルを削除する場合は、後で再度ビルドするための有効なベースがあることを確認する必要があります。
詳細については、WALアーカイブの ドキュメント を参照してください。
ストリーミングレプリケーションに関しては、pg_xlogにあるファイルのみを使用すると思います...(ファイルは送信される前にアーカイブされません、IIRC)
その場合、マスターのpg_dumpを6時間ごとに実行している場合、バックアップスクリプトを更新して、pg_dumpの開始時に存在するすべてのアーカイブファイルを消去することもできます(pg_dumpが当然完了した後)。
完全にではない... pg_dumpは、pg_restoreに提供できるデータベース全体の情報を含むファイルを作成します... PITRの場合、データベースファイルとWALファイルをコピーして、ファイルレベルの「バックアップ」を実際に作成する必要があります( pg_start_backupを発行した後)