最終更新日 2020年02月27日(木)

Postgres には、データをレプリケート、バックアップ、エクスポートするための複数の方法が用意されています。いくつかの方法はきわめて軽量で、実行中のデータベースのパフォーマンスへの影響もほとんどないのに対して、比較的コストが高く、負荷がかかるとデータベースに悪影響を与える可能性があるものもあります。

この記事では、Heroku Postgres がこれらの方法をどのように使用して継続的保護やデータの可搬性を提供しているか、またユーザーが自分のデータに適した方法をどのように選択すればよいかについて見ていきます。

異なるバックアップのタイプ

Postgres で使用可能なバックアップのタイプは、物理バックアップと論理バックアップに大きく分類されます。物理バックアップが、ファイルシステムのスナップショット、データベースクラスターファイルのバイナリコピー、または複製された外部システムである可能性があるのに対して、論理バックアップは、データベース内の特定のオブジェクトのスキーマやデータの SQL のようなダンプです。物理バックアップは、使用可能なデータ耐久性の計算量の最も少ない方法のいくつかを提供しますが、データの復元方法は非常に制限されています。論理バックアップはそれよりはるかに柔軟ですが、非常に低速で、バックアップや復元中に膨大な計算リソースを必要とする場合があります。以下に、これらの方法が Heroku Postgres でどのように使用されているかを見ていきます。

Heroku Postgres での物理バックアップ

Heroku Postgres は、データベースクラスターファイルのバイナリコピー (ベースバックアップともいう) と先行書き込みログ (WAL) ファイルを外部の信頼性の高いストレージに保持することによって、継続的保護のために物理バックアップを使用します。

ベースバックアップは、データベースが完全に使用可能な間に取得され、Postgres のデータファイルのそのままのコピーを作成します。これには、現在実行中のデータベースのデッドタプル、肥大化、インデックス、すべての構造的特性が含まれます。Heroku Postgres では、ベースバックアップの取得は約 10 MB/秒にレート制限されており、実行中のデータベースで発生する負荷は最小限に抑えられます。コミットされたトランザクションは WAL ファイルとして記録されます。このファイルは、ベースバックアップ上で再生できるため、これによりデータベースの状態を完全に再構成する方法が提供されます。ベースバックアップと WAL ファイルは、Postgres によって使用可能になるとすぐに、WAL-E​ という名前のアプリケーションを使用して AWS の S3 オブジェクトストアにプッシュされます。

Heroku Postgres によって管理されるデータベースはすべて、ベースバックアップと WAL ファイルを S3 に保持することによって継続的保護を提供します。また、永続的なベースバックアップと WAL ファイルをフェッチし、それを新しい Postgres インストール上で再生することによって、フォーク​とフォロワー​のデータベースが実装されます。これらの物理バックアップを可用性の高いオブジェクトストアに保存することにより、ハードウェア障害、データ破損、または大規模なサービス中断が発生した場合にデータベース全体を復旧することもできます。

Heroku Postgres での論理バックアップ

論理バックアップは、Heroku Postgres からデータをエクスポートし、それをほぼすべてのデータベースインストールに復元するきわめて柔軟な方法ですが、大規模なデータセットの移動はかなり負荷が高くなる場合があります。

論理バックアップは pg_dump​ を使用して取得され、ダンプファイルの形式に応じて pg_restore​ または psql​ を使用して復元できます。スクリプト形式のダンプは、取得の時点でデータベースを再構成する SQL コマンドのプレーンテキストファイルであり、psql を使用してパイプすることにより復元されます。アーカイブファイル形式は、スクリプト形式より柔軟かつ高性能であり、"カスタム" 形式では、アーカイブされたすべての項目の圧縮や便宜的な並べ替えが可能になります。アーカイブファイル形式は、pg_restore を使用して復元されます。

pg_dump

pg_dump​ アプリケーションは、データベース全体で一貫したスナップショットを生成するために、通常の Postgres 接続を使用して 1 つのトランザクションで一連の SQL COPY​ ステートメントを実行します。pg_dump​ は実行中に、排他的なロックを必要とする他の操作 (スキーマの変更など) を防止することができ、VACUUM やその他の自動メンテナンスプロセス​の妨げになることがあります。これは、長時間実行トランザクションが、これらのトランザクションに表示されている行の autovacuum によるフリーズを妨げるためです。

pg_dump​ は、1 つのバックエンドを使用して、循環バッファ経由でデータベース内のすべてのライブタプルを読み取ります。このバッファは Postgres のキャッシュを保持していますが、OS やファイルシステムのキャッシュに取って代わる予定であり、これらのキャッシュはなくなる可能性があります。pg_dump​ のバックエンドは、できるだけ多くのファイルシステム I/O を消費し、並列に実行されているクエリとの間でリソースを競合します。pg_dump​ によって生成されるファイルは、データベースのライブデータセットと、インデックス自体ではなく、インデックスを再作成する方法に関する説明のみが含まれるため、pg_database_size​ によって報告されるデータベースのサイズよりはるかに小さくなります。また、"カスタム" アーカイブファイル形式が使用されている場合は、デフォルトで圧縮されます。

pg_restore

pg_restore​ アプリケーションも同様に、通常の Postgres 接続を使用してダンプを Postgres データベースにロードします。復元によって、必要なスキーマの作成、COPY コマンドによるデータのロード、インデックスの作成、制約の追加、およびソースデータベースからダンプされたすべてのトリガーの作成が行われます。データのロード、インデックスの作成、制約の作成の各フェーズは、復元されたデータの通常の操作での書き込み、処理、変更のためにそれぞれディスク I/O と計算を必要とするため、きわめて低速になることがあります。復元の特定の部分を、複数の並列接続を通して実行できます。これは、pg_restore​ への --jobs=number-of-jobs​ コマンドラインフラグを使用して実現できます。各ジョブが 1 つのプロセスであるため、データベースインスタンスで CPU コアあたり複数のジョブを使用すると、リソースの競合につながり、パフォーマンスが低下する可能性があります。

PGBackups

Heroku 上で実行される pg_dump​ と pg_restore​ はどちらも、Heroku Postgres 経由で使用できます。PGBackups の定期的な実行または heroku pg:backups:capture​ の手動の実行中に、PGBackups は、データベースのダンプを取得し、それを S3 にアップロードする専用の dyno を起動します。pg:backups capture​ の実行は、通常の psql​ 接続経由でキャンセルできます。

$ heroku pg:psql
=> SELECT pid, query FROM pg_stat_activity WHERE query LIKE 'COPY%';
  pid  |                       query
-------+----------------------------------------------------
 21374 | COPY public.users (id, created_at, name) TO stdout;
(1 row)
=> SELECT pg_cancel_backend(21374);
 pg_cancel_backend
-------------------
 t
(1 row)

データをデータベースに復元する場合、heroku pg:backups:restore​ は Heroku 上で実行される dyno からアクセスできるすべてのダンプファイル (S3 上で使用可能なものなど) を取得し、それを Heroku Postgres データベースに復元します。ターゲットデータベースは、復元プロセスが実行される前に削除されることに注意してください。

論理バックアップを Heroku Postgres データベース間で直接転送するために、heroku pg:copy​ は専用の dyno を使用して pg_dump​ の出力を pg_restore​ に直接パイプします。これにより、ダンプファイルを Heroku の外部にある場所に転送する必要がなくなります。このデータ転送はまた、転送をより明確に可視化できるように、パイプビューアー​として有名なアプリケーションである pv​ 経由でもパイプされます。ただし、インデックスの作成、制約の追加、pg:copy​ 実行の最後での基本的なサニティチェックは pv​ のログ記録に反映されないため、転送がハングアップしているように見える可能性がありますが、バックグラウンドで動作しています。

論理バックアップのパフォーマンスへの影響

データベースから論理バックアップを取得すると、負荷が増加します。すべてのデータが読み取られると、論理バックアップの取得では、適切にキャッシュされたデータを Postgres 以外のキャッシュから削除し、有限のディスク I/O 容量を消費し、自動メンテナンスタスクを一時停止して、他のクエリのパフォーマンスを低下させます。データベースのサイズや、データベースにかかる負荷が増加すると、この低下したパフォーマンスと無視された自動メンテナンスの期間も増加します。想定外の不具合を回避するには、データベースのパフォーマンスとバックアップ要件のバランスをとることが必要です。

一般に、PGBackups は、適度な負荷がかかった最大 20 GB までのデータベースを対象にしています。より大規模なデータベースをバックアップするために必要な I/O、メモリ、CPU の競合は適度な負荷でもきわめて激しくなり、実行時間が長くなると、バックアップの取得を早い段階で終了させるエラーが発生する可能性が高くなります。

物理バックアップと論理バックアップの組み合わせ

フォークとフォロワーを使用すると、論理バックアップの負荷を削減できます。フォロワーから論理バックアップを取得すると、リーダーのパフォーマンスが保持され、ダンプを成功させるために必要なだけ多くのリソースをバックアップ操作で消費できるようになります。また、短期間のフォークを起動すると、新しいフォークの初期のベースバックアップがディスク I/O 用の論理バックアップと競合するにもかかわらず、プライマリデータベースのパフォーマンスに影響を与えずに論理バックアップを取得することもできます。論理バックアップの取得についての詳細は、上記および「Heroku Postgres Backups​」(Heroku Postgres のバックアップ) を参照してください。

PGBackups は、DATABASE_URL​ などの定義された任意のデータベース環境設定にあるデータベースの自動バックアップを取得できます。 これにより、論理バックアップを取得するタイミングと場所をチューニングできます。