web-dev-qa-db-ja.com

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()はアプリケーションに影響を与えますか？

postgresqlreplication
19
Daniel

pg_start_backupは、dezsoが指摘するように、チェックポイントを実行します。これは影響を与えますが、データベースはとにかく非常に定期的にチェックポイントを実行し、機能するためにはチェックポイントを実行する必要があるため、明らかに問題ではありません。初期のチェックポイントとは、蓄積されるデータが少ないことを意味します。つまり、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を安全に使用できるかどうかを判断するのは困難です。ほとんどの人は可能ですが、ハードウェアができることのエッジに近く、タイミング要件が厳しく、ストールのリスクを負えず、チャーンテーブルが非常に大きく、テーブルが非常に大きい場合、問題が発生する可能性があります。 。

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

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

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

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

基本的に、アイデアは、自由にコピーできる各ボリュームの特定の時点を取得することにより、DBがチェックポイントを遅延させる必要がある時間を短縮することです。

11
Craig Ringer

これは墓掘りですが、ここで何か修正する必要があります。

以前の答えは述べています：

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

それは真実ではない。システムは、設定に記載されているWALの数を維持します（cf オンラインドキュメント ）。したがって、基本的には、次の値の方が高くなります。

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

このケースを想像してみましょう：

  • 何百ものギグがコピーされるので、バックアップには長い時間がかかります
  • wAL保持が小さい（たとえば、checkpoint_segmentsが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はそれを行いません。

7
sterfield

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

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

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

4
Riki_tiki_tavi