PostgreSQL：pg_start_backup（）を、負荷がかかっている稼働中のdbで実行できますか？

確立された複製が壊れています（ダウンタイム中に「要求されたWALセグメントは既に削除されています」）マスターを簡単に停止することは簡単にできません。

できますか

1. pg_start_backup()、
2. rsync ${PGDATA}/ マスターからスレーブ、
3. pg_stop_backup()

...マスターpostgresqlがまだ全負荷下にある間に？（またはにpg_start_backup()つながる

• テーブルロック、
• I / Oブロック、
• 矛盾、
• 火災警報、
• データベース応答が遅い

つまり、pg_start_backup()アプリケーションに影響しますか？

pg_start_backupdezsoが指摘しているように、チェックポイントを実行します。これは影響を及ぼしますが、データベースはとにかくかなり定期的にチェックポイントを実行し、機能するためにそうする必要があるため、それらは明らかにあなたにとって問題ではありません。早期チェックポイントとは、蓄積されるデータが少ないことを意味します。つまり、チェックポイントからのpg_start_backup影響が通常よりも低いことを意味します。

心配する必要があるのは、rsyncまたは同等のpg_basebackup手順です。これからの読み取りI / Oはシーケンシャルであるため、それほど悪くはありませんが、データベースのI / Oパフォーマンスを大幅に低下させる可能性があります。また、RAMキャッシュからホットデータを押し出して、 -使用済みデータ。必要なデータが読み戻されるため、キャッシュのスラッシングが発生します。

niceおよびioniceを使用して、I / Oの影響を制限できます（ただし、キャッシュの影響は制限されません）。ただし、それにはコストがかかります。バックアップには時間がかかり、バックアップを完了しpg_stop_backupてシステムを実行するまで-私が理解しているように-削除できないWALを蓄積し、バックアップ実行の最後にBIGチェックポイントのチェックポイント負債を蓄積し、テーブルとインデックスを蓄積していますデッド行をクリーンアップできないため、膨張します。したがって、特に非常に高いチャーンテーブルがある場合は、バックアップを永久に実行する余裕はありません。

最後に、それはあなたが安全に使用できるかどうかを言うのは難しいですpg_start_backupし、pg_stop_backupお使いの環境でのホットバックアップのために。ほとんどの人はできますが、ハードウェアができることの限界に近づいていて、厳しいタイミング要件があり、ストールのリスクを負う余裕がなく、非常に大きな解約テーブルと非常に大きなテーブルがある場合、面倒かもしれません。

残念ながら、それをテストして確認する必要があります。

可能であれば、CHECKPOINTLVM、SANのツール、EBSなどを使用して、データベースが存在するボリュームのアトミックスナップショットを作成する価値があるかもしれません。これを行うことができる場合は、自由にスナップショットをコピーできます。このアプローチは、PITR /ウォームスタンバイ/ホットスタンバイのベースバックアップの作成には適していませんが、静的バックアップコピーには最適であり、システムへの影響ははるかに小さくなります。ただし、スナップショットがアトミックで、WALを含むデータベース全体が単一のボリューム上にある場合にのみ、これを行うことができます。

まだ調査していない可能性の1つは、2つのアプローチを組み合わせることです。私は、可能性があると思います（テストされておらず、おそらく間違っていて安全ではありません、私はまだ知りません）：

• pg_start_backup
• すべてのテーブルスペース、メインのデータディレクトリ、xlogボリュームのスナップショットをトリガーします
• pg_stop_backup
• から最終アーカイブまでWALをコピーします pg_stop_backup
• スナップショットボリュームからデータをコピーします

基本的には、各ボリュームの特定の時点を自由にコピーできるようにすることで、DBがチェックポイントを遅らせる時間を短縮することです。

これは重大な掘削ですが、ここで何かを修正する必要があります。

前の答えは次のとおりです。

niceとioniceを使用して、I / Oの影響を制限できます（ただし、キャッシュの影響は制限されません）。ただし、それにはコストがかかります。バックアップには時間がかかり、バックアップを完了してpg_stop_backupを実行するまで、システムは-私が理解しているように-削除できないWALを蓄積し、バックアップ実行の最後にBIGチェックポイントのチェックポイント借金を蓄積し、テーブルを蓄積していますデッド行をクリーンアップできないため、インデックスが膨張します。したがって、特に非常に高いチャーンテーブルがある場合は、バックアップを永久に実行する余裕はありません。

それは真実ではない。システムは、構成に記載されているWALの数を保持します（オンラインドキュメントを参照）。したがって、基本的に、次の値が高いほど：

• （2 + checkpoint_completion_ratio）* checkpoint_segments + 1
• wal_keep_segments

この場合を想像してみましょう：

• コピーするギグが数百あるため、バックアップに時間がかかります
• WAL保持が小さい（checkpoint_segments to 3、たとえば）
• WALアーカイブをセットアップしていない

「pg_start_backup（）」を開始した後、バックアップ中にWALファイルがローテーションします。バックアップが完了すると、別のデータベースエンジンでバックアップを復元しようとします。起動時のエンジンは、少なくとも「pg_start_backup（）」を発行したときに生成されたWALファイルを要求します。

pg_start_backup 
-----------------
B/D0020F18
(1 row)

WALファイル "0000000x0000000B000000D0"（xはTimelineID）を指定するまで、データベースは起動を受け入れません。このWALファイルは、システムが起動するための最低限のファイルです。もちろん、このファイルだけでは、残りのデータは持っていないWALファイルにあるため、データは失われますが、少なくとも機能するデータベースエンジンが必要です。

したがって、WALアーカイブを行うか、必要なWALファイルを自分で保存する必要がありますが、Postgresqlはそれを行いません。

PostgreSQLでの私の経験としては、その瞬間にパフォーマンスに大きな影響を与えない限り、比較的安全な操作です。それがある場合は、すべてのクライアントからの書き込みを一時的に一時停止することをお勧めします。

負荷の下でマスターをスレーブに同期しているときに重大なケースが1つしかありませんでした。これはOOMキラーが原因でした（はい、データベースノードでOOM Killerを完全に無効にする必要があります。その日は知りませんでした）。

そのため、夜間バックアップからデータベースを復元し、再生のためにpg_archiveディレクトリからすべてのWALセグメントをpostgresに渡しました（それらをpg_xlogフォルダにコピーしただけです）。すべてがうまくいきましたが、もちろんダウンタイムは避けられませんでした。