PostgreSQL先行ログアーカイブモード

Question

私はPostgreSQLを取り巻くさまざまなこと、およびバックアップがWALおよびCommvault Simpanaとどのように連携するかを理解しようとしています。 Simpanaはすべてが大丈夫であると私に言っていますが、ファイルはWAL Archiveディレクトリに残っています。

旅を始めましょう。

環境

PostgreSQLとOSのバージョン

PostgreSQL 9.3はUbuntu 14.04.3 LTSサーバーで実行されています。

Postgres WAL設定

Postgres.confファイルは、WALアーカイブ用に次のように設定されています。

#------------------------------------------------------------------------------ # WRITE AHEAD LOG #------------------------------------------------------------------------------ # - Settings - #wal_level = minimal # minimal, archive, or hot_standby wal_level = archive [...] # - Archiving - archive_mode = on #archive_mode = off # allows archiving to be done # (change requires restart) archive_command = 'cp %p /pgsql-backup/archive/postgres1/%f' # command to use to archive a logfile segment # archive_command = '' # command to use to archive a logfile segment # placeholders: %p = path of file to archive # %f = file name only # e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f' #archive_timeout = 0 # force a logfile segment switch after this # number of seconds; 0 disables

test ...の部分がarchive_commandに残っていると、Simpanaバックアップが壊れるため、省略しました。

上記の構成では、WALファイルが/pg_xlog/ディレクトリから/pgsql-backup/archive/postgres1/ディレクトリにコピーされます。

pg_basebackupにより、不要になりました
wALファイルがいっぱいになり（デフォルトは16MB）、使用されなくなった

Commvault Simpana

クライアントコンピューターは、PostgreSQLデータベース/インスタンスとアーカイブログディレクトリ内のWALファイルがバックアップされるように構成されています。 PostgreSQLクライアントにSimpanaオプションの「アーカイブの削除」が設定されているため、不要になった場合はWALファイルを削除する必要があります。

予想される動作

SimpanaはPostgreSQLのネイティブコマンドを使用してバックアップを実行しているため、Simpanaが完全バックアップまたはWALバックアップを完了すると、/pgsql-backup/archive/postgres1/ディレクトリ内のファイルが削除されることを期待しています。

効果的な行動

Simpanaがバックアップを実行した後で/pgsql-backup/archive/postgres1/ディレクトリを確認すると、ディレクトリに0000000300000037000000nn.mmmmmmmm.backup構文のファイルがもう1つあります。 0000000300000037000000nn.mmmmmmmm.backupファイルはpg_basebackupを使用したデータベース/インスタンスのPostgreSQLバックアップ後にのみ作成されるため、これはSimpanaがネイティブPostgreSQLコマンドを使用してバックアップを実行しているというヒントです。これは、PostgreSQL 9.3のドキュメントを読んだ後の私の結論です。

以下は、ディレクトリの内容の例です。

[...] 00000003000000370000007A 00000003000000370000007B.00000028.backup 000000030000003700000091.00000028.backup 000000030000003700000093.00000028.backup 000000030000003700000095.00000028.backup 000000030000003700000097.00000028.backup 000000030000003700000099.00000028.backup 00000003000000370000009B.00000028.backup

PostgreSQLドキュメント

公式文書には、

バックアップを利用するには、ファイルシステムバックアップ中およびバックアップ後に生成されたすべてのWALセグメントファイルを保持する必要があります。これを支援するために、ベースバックアッププロセスは、WALアーカイブ領域にすぐに保存されるバックアップ履歴ファイルを作成します。このファイルは、ファイルシステムのバックアップに必要な最初のWALセグメントファイルにちなんで名付けられています。たとえば、開始WALファイルが0000000100001234000055CDの場合、バックアップ履歴ファイルは0000000100001234000055CD.007C9330.backupのような名前になります。（ファイル名の2番目の部分は、WALファイル内の正確な位置を表しており、通常は無視できます。）ファイルシステムのバックアップとバックアップ中に使用されたWALセグメントファイルを安全にアーカイブしたら（バックアップ履歴で指定）ファイル）、名前が数値的に小さいすべてのアーカイブされたWALセグメントは、ファイルシステムのバックアップを回復するために不要になり、削除できます。ただし、データを回復できることを確実にするために、いくつかのバックアップセットを保持することを検討する必要があります。

これは、SimpanaがネイティブのPostgreSQLコマンドを使用して、データベース/インスタンスとそのWALアーカイブログファイルをディレクトリ/pgsql-backup/archive/postgres1/にバックアップしているという私の結論を覆します。

ドキュメントによると、nnnnnnnnnnnnnnnnnnnnnnn.mmmmmmmm.backupファイルは、ロールフォワードリカバリが成功するために必要な最も古いWALファイルへのポインタです。 Archive Logディレクトリ内の古いWALファイルは削除される可能性があり、不要になりました。

私を驚かせたのは、対応する* .mmmmmmmm.backupポインタファイルのないWALファイルがアーカイブログディレクトリにあることです。

ご質問

バックアップにSimpanaを使用していなかった場合、WALアーカイブディレクトリの* .mmmmmmmm.backupファイルを誰が削除する必要がありますか？ pg_archivecleanupコマンド？
Archive Logディレクトリにある他のすべてのWALファイルと同様に、削除されているはずなのに、なぜArchive Logディレクトリにまだ完全なWALファイルがあるのですか？
アーカイブログディレクトリに、既存の00000003000000370000007A.mmmmmmmm.backup WALファイル用の00000003000000370000007Aファイルがないのはなぜですか？

私はあなたの返答を楽しみにしており、誰かがどこかにSimpanaとPostgreSQLの同様の設定があることを願っています。

jjanes · Accepted Answer

これは基本的に、PostgreSQLではなくCommvault Simpanaに関する質問のようです。 Commvaultは商用ソフトウェアのようなので、サポートデスクに連絡して幸運を祈るかもしれません。

予想される動作SimpanaはPostgreSQLネイティブコマンドを使用してバックアップを実行しているため、Simpanaが完全バックアップまたはWALバックアップを完了すると、/ pgsql-backup/archive/postgres1 /ディレクトリ内のファイルが削除されることを期待します。

ここで「WALバックアップ」の意味がわかりません。それはシンパナに固有の用語ですか？それは、元のアーカイブディレクトリにあるWALファイルが一部のオフサイトストレージにコピーされたことを意味するだけですか？

質問バックアップにSimpanaを使用していなかった場合、WALアーカイブディレクトリの* .mmmmmmmm.backupファイルを誰が削除する必要がありますか？ pg_archivecleanupコマンド？

Simpanaを使用していない場合は、他のものを使用することになります。他のことについてはお伝えできません。選択肢はたくさんあります。 pg_archivecleanupはそのような方法の1つであり、最近は時代遅れになっているように見えます。 WALファイルをスタンバイで安全に保存（または再生）できる長さだけ維持したい場合は、「ストリーミングレプリケーション」を使用して、ログ配布を完全に廃止します。

または、これまでに取った最初の基本バックアップ（空のデータベースを初期化した直後）とそれ以降にアーカイブされたすべてのWALファイルを永続的に保持するポリシーを設定して、履歴の任意の時点にポイントインタイムリカバリを実行できます。データベースの。

Archive Logディレクトリにある他のすべてのWALファイルと同様に、削除されているはずなのに、なぜArchive Logディレクトリにまだ完全なWALファイルがあるのですか？

Simpanaがアーカイブをクリーンアップすることを決定したときのように見えますが、現在必要な最も古いものより古いすべてのWALファイルを削除するのではなく、最後にクリーンアップを行ったときにまだ必要なものから始まり、終了するファイルの範囲を削除します現在必要なものの直前のもの。

これが事実である場合、アーカイブをオンにした直後に、Simpanaがアクティブ化される前（またはそのベアリングを取得する前）にWALファイルがPostgreSQLによってアーカイブされた場合、そのファイルは削除されません。

アーカイブログディレクトリにまだ存在する00000003000000370000007A WALファイルの00000003000000370000007A.mmmmmmmm.backupファイルがないのはなぜですか？

00000003000000370000007AがアクティブなWALファイルである期間中にバックアップが開始されなかった場合、最初に00000003000000370000007A.mmmmmmmm.backupファイルが存在することはありません。

ddanny · Answer

Simpana postgresバックアップにも同じ問題があります。ドキュメントは述べています：

ログのみバックアップの一部としてバックアップされるすべてのファイルは何ですか？現在のバックアップサイクルに関連するトランザクションログファイルのみがバックアップされます。ログディレクトリの内容全体はバックアップされません。たとえば、時刻T1にログバックアップを実行し、その後時刻T2に完全バックアップ（データとログ）を実行するとします。 T1とT2の間に生成されたトランザクションログファイルは、現在のバックアップサイクルには関係がないため、最新の完全バックアップには含まれません。また、.backupファイルは、ログのアーカイブの一部としてPostgreSQL Serverによって作成された一時ファイルであり、ログのバックアップの一部としてはバックアップされません。アーカイブ削除オプションが有効な場合、ログファイルのクリーンアップはどのように行われますか？

アーカイブ削除オプションが有効な場合、ログファイルのクリーンアップはどのように行われますか？ Archive Deleteオプションを有効にすると、ログバックアップの一部としてバックアップされたトランザクションログファイルのみが削除されます。以前のバックアップ試行中に削除されなかったトランザクションログファイルはクリーンアップされません。また、トランザクションログファイルの継続的なアーカイブにより、ログのバックアップが成功した後、WALディレクトリに新しいトランザクションログファイルが表示される場合があります。したがって、ログバックアップの一部ではないトランザクションログファイル、およびPostgreSQLサーバーによって作成された一時ファイルは、Logディレクトリに残されます。

したがって、次の完全バックアップの直前に、追加のログのみのバックアップを作成しない場合。これらのウォルはすべてバックアップ/削除されることはありません。さらに悪いことに、ディスク障害が発生した場合、この期間までPITRすることはできません。