web-dev-qa-db-ja.com

どのPostgresqlWALファイルをWALアーカイブフォルダーから安全に削除できますか

現状

そのため、Postgresを実行しているデータロギングコンピューター上の独立した内部ハードドライブにWALアーカイブを設定しています。 WALアーカイブを含むハードドライブがいっぱいになっているので、最初のベースバックアップを含むすべてのWALアーカイブファイルを削除して、外部バックアップドライブにアーカイブしたいと思います。

ディレクトリ構造は次のようになります：

D：/ WALBACKUP /は、すべてのWALファイル（00000110000.CA00000004など）の親フォルダーです。

D：/ WALBACKUP/BASEBACKUP /これは初期ベースバックアップの.tarを保持します

私が持っている質問は：

  • ベースバックアップを含め、現在のWALアーカイブファイル（000000000001.CA0000 ..など）を除くすべてのWALファイルを文字通り安全に移動し、それらを別のhddに移動できますか？ （データベースはライブでデータを受信して​​いることに注意してください）

乾杯！

postgresqlarchivingwal
6
undercurrent

WALアーカイブ

pg_archivecleanupコマンドを使用して、特定の基本バックアップで必要とされないアーカイブ（notpg_xlog）からWALを削除できます。

一般的には、PgBarmanまたは同様のツールを使用して、基本バックアップとWAL保持を自動化することをお勧めします。簡単でエラーが発生しにくくなります。

pg_xlog

pg_xlogからWALを手動で削除しないでください。 WALが多すぎる場合は、次のようにします。

  • wal_keep_segments設定はWALを維持しています。
  • archive_modeがオンでarchive_commandが設定されていますが、正しく機能していません（ログを確認してください）。
  • あなたのcheckpoint_segmentsは途方もなく高いので、WALを生成しすぎています。または
  • wALの削除を妨げているレプリケーションスロット（pg_replication_slotsビューを参照）があります。

WALが保持される原因となっている問題を修正する必要があります。設定を変更しても何も起こらなかった場合は、手動のCHECKPOINTコマンドを実行してください。

オフラインサーバーがあり、起動するためにWALを削除する必要がある場合は、必要に応じてpg_archivecleanupを使用できます。サーバー自体が必要としないWALのみを削除する方法を知っています...しかしアーカイブベースのバックアップ、ストリーミングレプリカなどを壊す可能性があります。したがって、mustでない限り、使用しないでください。

15
Craig Ringer

WALファイルは増分であるため、簡単な答えは次のとおりです。ファイルを破棄することはできません。解決策は、新しい基本バックアップを作成することです。そうすれば、以前のすべてのWALを削除できます。

WALファイルには、テーブルを変更する個々のステートメントが含まれているため、古いWALを破棄すると、データベースの状態を確実に復元できないため、回復プロセスは失敗します（欠落しているWALファイルをサイレントにスキップしません）。 WALプロセスを混乱させることなく、WALファイルを別の場所に移動できますが、過去のある時点からデータベースを回復する必要がある場合は、すべてのWALファイルを1つの場所から再び利用できるようにする必要があります。ディスク容量が不足している場合は、基本バックアップとすべてのWALファイルを保存するのに十分な容量がある場所から回復することを意味する場合があります。ここでの主な問題は、インシデント後にデータベース全体を復元するのに十分な速度でそれを実行できるかどうかです。

もう1つの問題は、修正が必要な問題が発生した場所と時期を特定できない場合、唯一のオプションは、基本バックアップから開始して、すべてのWALファイルを再生することです。この手順は難しくありませんが、古いベースバックアップがあり、処理するWALファイルが多数ある場合、これには多くの時間がかかります。

一般に、この場合の最善のアプローチは、xか月ごとに新しい基本バックアップを作成し、その基本バックアップでWALを収集することです。新しいベースバックアップが実行されるたびに、古いベースバックアップとそれに続くWALを削除するか、安価なオフラインストレージ（DVD、テープなど）に移動できます。重大なインシデントが発生した場合は、最近の基本バックアップとそれ以降に収集された比較的少数のWALファイルから、データベースを既知の正しい状態にすばやく復元できます。

7
Patrick

私たちが求めた解決策は、毎晩 pg_basebackup を実行することです。これによりベースバックアップが作成され、後で pg_archivecleanup を使用して、次のようなものを使用して、そのベースの前にあるすべての「古い」WALファイルをクリーンアップできます。

"%POSTGRES_INSTALLDIR%\bin\pg_archivecleanup" -d %WAL_backup_dir% %newestBaseFile%

幸い、まだ回復する必要はありませんでしたが、理論的には機能するはずです。

6
Viorel

レプリケーションアーキテクチャでWALディレクトリを安全にクリーンアップする方法を検索してこれを見つけた場合は、offlineレプリカ、この場合はレプリカが来るのを待っている未使用のレプリカスロットからの残りがある可能性があるシナリオを検討してください。オンラインに戻って、マスターDBに多くのWALアーカイブを保持します。

私たちの場合、ハードウェア障害が原因でレプリカがダウンするという問題が発生しました。マスターDBでレプリカをreplica_slotと一緒に再作成する必要がありましたが、以前に使用したレプリカを削除するのを忘れていました。 PSQLが未使用のWALを取り除き、すべてが良好であることをクリアすると、.

1
Aldo