バックアップ ============ .. raw:: html .. Note:: このセクションでは、PostgreSQLの**物理バックアップ**について説明します。 PostgreSQLは、 `pg_dump` ユーティリティを使用した論理バックアップもサポートしていますが、これらは**ビジネス継続性に適しておらず**、CloudNativePGによって**管理されません**。 `pg_dump` を使用する場合は、 :ref:`*Troubleshooting / Emergency backup* section <バックアップ>` を参照してください。 ガイダンス用に。 .. Important:: バージョン1.26から、ネイティブバックアップおよびリカバリー機能は、コアオペレーターの**段階的にフェーズアウト**され、公式CNPG-Iプラグインに移動されます。この移行は、**WALアーカイブ**、*物理ベースバックアップ**の管理を標準化する拡張可能なインターフェイス**CNPG-I**によって有効になる**バックアップに依存しないアーキテクチャ**へのCloudNativePGのシフトと一致しています。 、および対応する**リカバリプロセス**。 CloudNativePGは現在、2つの主な方法で **PostgreSQLクラスターの物理バックアップ** をサポートしています。 - **`CNPG-I `_ プラグイン経由** CloudNativePGコミュニティは `**Barman Cloud Plugin** `_ を公式にサポート オブジェクトストレージサービスとの統合用。 - **ネイティブ** 、以下をサポート *( Barman Cloudプラグインを優先して1.26から非推奨ですが)* - :ref:`Kubernetes Volume Snapshots <付録A-ボリュームスナップショットのバックアップ>` 、基になるストレージクラスでサポートされている場合 CloudNativePGでバックアップ戦略を選択する前に、 :ref:`主要なコンセプト <主要なコンセプト>` でカバーされている基本的な概念を理解することが重要です セクション。これらには、WALアーカイブ、ホットおよびコールドバックアップ、スタンバイからのバックアップの実行などが含まれます。 主要なコンセプト ---------------- PostgreSQLは、ファイルシステムレベルの物理コピーに基づいて、ファーストクラスのバックアップおよびリカバリー機能をネイティブに提供します。これらはミッションクリティカルな運用データベースで15年以上使用され、世界中の組織がPostgresでディザスターリカバリー目標を達成するのを支援してきました。 CloudNativePGでは、各PostgreSQLクラスターのバックアップインフラストラクチャは次のリソースで構成されます。 - **WALアーカイブ** Postgresによって継続的に書き込まれ、データ耐久性のためにアーカイブされるWALファイルトランザクションログを含む場所 - **物理ベースバックアップ** PostgreSQLがデータベースにデータを保存するために使用するすべてのファイルのコピー主に\ ``PGDATA`` およびテーブルスペース CNPG-Iは、WALアーカイブアーカイブとリストア操作の両方、およびベースバックアップおよび対応する復元プロセスを管理するための汎用かつ拡張可能なインターフェイスを提供します。 WALアーカイブ ^^^^^^^^^^^^^ PostgreSQLのWALアーカイブは、 **継続的バックアップ** の中心であり、次の理由で基本的なものです。 - **ホットバックアップ** サーバーをシャットダウンせずに、Postgresクラスタープライマリまたはスタンバイのインスタンスから物理ベースのバックアップを取得する可能性。オンラインバックアップとしても知られています - **ポイント インタイム リカバリー** PITR システムで最初に使用可能なベースバックアップから任意の時点で復旧する可能性。 .. Warning:: WALアーカイブだけでは役に立ちません。物理ベースのバックアップがないと、PostgreSQLクラスターを復元できません。 一般に、WALアーカイブの存在により、PostgreSQLクラスターの復元力が強化され、各インスタンスは、必要に応じてアーカイブから必要なWALファイルを取得できます。通常、WALアーカイブの保持期間は、通常これらのファイルをリサイクルするPostgresインスタンスよりも長くなります。 。 このユースケースは、WALアーカイブに依存するだけで長距離にわたって同期でき、さまざまなリージョンにわたってディザスターリカバリー目標を拡張できるため、 :ref:`レプリカクラスター <レプリカクラスター>` に拡張することもできます。 :ref:`configure a WAL archive ` を実行すると、CloudNativePGは、リージョンを超えても、ディザスターリカバリーに :ref:`PgBouncerPoolMode {postgresql-cnpg-io-v1-PgBouncerPoolMode} ` <= 5分をすぐに提供します。 .. Important:: 常に本番でWALアーカイブをセットアップすることをお勧めします。通常ステージング環境と開発環境が関係する既知のユースケースがあり、上記の利点はいずれも必要とされず、WALアーカイブは必要ありません。この場合のRPOは、24時間毎日のバックアップまたは無限バックアップなしなどの任意の値です。 コールドおよびホットバックアップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ホットバックアップは前のセクションで既に定義されています。これらはWALアーカイブの存在を必要とし、最新のデータベース管理システムでは標準です。 **コールドバックアップ** は、オフラインバックアップとしても知られ、代わりに、PostgreSQLインスタンススタンバイまたはプライマリがシャットダウンしたときに取得される物理ベースバックアップです。これらは定義ごとに一貫しており、シャットダウンされた時点のデータベースのスナップショットを表します。 その結果、PostgreSQLインスタンスは、WALアーカイブを必要とせずにコールドバックアップから再起動できますが、利用可能な場合はそれを利用できます前のセクションで強調表示した復旧面のすべての利点を備えています。 RPOが高く1時間または24時間など、保持期間が短い状況では、コールドバックアップは、ディザスターリカバリー計画で検討される実行可能なオプションを表します。 使用可能なバックアップオプションの比較:オブジェクトストアとボリュームスナップショット ------------------------------------------------------------------------------------- CloudNativePGは現在、物理バックアップの2つの主要なアプローチをサポートしています。 - **オブジェクトストアベースのバックアップ** 、 `**Barman Cloud Plugin** `_ または :ref:`**deprecated native integration** <付録B-オブジェクトストアのバックアップ>` 経由 - :ref:`**Volume Snapshots** <付録A-ボリュームスナップショットのバックアップ>` 、Kubernetes CSIインターフェイスとサポートされているストレージクラスを使用 .. Important:: CNPG-Iは、サードパーティが独自のバックアッププラグインをビルドおよび統合できるように設計されています。時間の経過とともに、サポートされているバックアップソリューションのエコシステムが成長すると予想されます。 オブジェクトストアベースのバックアップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ オブジェクトストアへのバックアップAWS S3、Azure Blob、GCSなど - 常にWALアーカイブが必要 - ホットバックアップのみをサポート - インクリメンタルまたは差分コピーをサポートしていません - リテンションポリシーのサポート ボリュームスナップショット ^^^^^^^^^^^^^^^^^^^^^^^^^^ ネイティブボリュームのスナップショット - WALアーカイブは必要ありませんが、運用環境での使用を強くお勧めします - 基になるストレージクラスの機能に応じて、インクリメンタルおよび差分コピーをサポート - ホットおよびコールドバックアップの両方をサポート - リテンションポリシーをサポートしていません 2つの間の選択 ^^^^^^^^^^^^^ 最適なアプローチは、環境と操作要件によって異なります。次の要素を考慮します。 - **オブジェクトストアの可用性** Kubernetesクラスターが、安定したネットワーキングレイヤーを含む信頼できるオブジェクトストレージソリューションにアクセスできることを確認します。 - **ストレージクラス機能** ストレージクラスが、インクリメンタル/差分機能を備えたCSIボリュームスナップショットをサポートしていることを確認します。 - **データベースサイズ** 非常に大規模なデータベースVLDBの場合、コピーオンライトテクノロジーによる高速なリカバリーが可能になるため、 **ボリュームスナップショットが一般的に優先されます** 。これにより、 :ref:`Recovery Time Objective (RTO) <始める前に>` が大幅に向上します。 - **データモビリティ** オブジェクトストアベースのバックアップは、リージョンまたは環境を超えてバックアップをレプリケートまたは保存するためのより高い柔軟性を提供する場合があります。 - **操作の慣れ** ストレージの管理におけるチームの経験と自信に最も適した方法を選択します。 比較の概要 ^^^^^^^^^^ .. csv-table:: :header: Feature,Object Store,Volume Snapshots :widths: 12,25,15 :align: left :class: longtable **WAL archiving** ,Required,Recommended^1^ **Cold backup** ,NO,OK **Hot backup** ,OK,OK **Incremental copy** ,NO,OK^2^ **Differential copy** ,NO,OK^2^ **Backup from a standby** ,OK,OK **Snapshot recovery** ,NO^3^,OK **Retention policies** ,OK,NO **Point-in-Time Recovery (PITR)** ,OK,Requires WAL archive **Underlying technology** ,Barman Cloud,Kubernetes API .. Important:: オンデマンドバックアップには、PostgreSQLスーパーユーザーまたはアプリケーションユーザーのKubernetesシークレットは含まれません。これらのシークレットが、より広範なKubernetesクラスターバックアップ戦略に含まれていることを確認する必要があります。 バックアップ方法 ---------------- CloudNativePGは現在、スケジュールされたバックアップとオンデマンドバックアップとして次のバックアップ方法をサポートしています。 - ``plugin`` – CNPG-Iプラグインを使用します ``.spec.pluginConfiguration`` が必要 - ``volumeSnapshot`` – ネイティブ :ref:`Kubernetes volume snapshots <付録A-ボリュームスナップショットのバックアップ>` を使用します - ``barmanObjectStore`` – :ref:`Barman Cloud for object storage <付録B-オブジェクトストアのバックアップ>` を使用します - `Barman Cloud Plugin `_ を優先してv1.26から非推奨ですが、下位互換性の為のデフォルトです。 ``.spec.method`` フィールドデフォルト\ ``barmanObjectStore`` を使用して方法を指定します。 クラスターがボリュームスナップショットをサポートするように構成されている場合、次のようなスケジュールされたスナップショットバックアップを有効にできます。 .. code:: yaml spec: method: volumeSnapshot バックアップ方法としてBarman Cloudプラグインを使用するには、 ``method: plugin`` を設定し、それに応じてプラグインを構成します。 :ref:`Performing a Base Backup <バックアップ>` に例があります。 スタンバイからのバックアップ ---------------------------- ベースバックアップの取得には、PostgreSQLインスタンスのディスク上のデータセット全体の読み取りが含まれます。これにより、I/O競合が発生し、アクティブなワークロードのパフォーマンスに影響を与える可能性があります。 この影響を軽減するために、 **CloudNativePGは、読み取り専用レプリカからバックアップを実行するPostgreSQLのビルトイン機能を活用して、スタンバイインスタンス** からのバックアップ取得をサポートしています。 デフォルトでは、バックアップはクラスター内の **最新のレプリカ** で実行されます。使用可能なレプリカがない場合、バックアップは **プライマリインスタンス** にフォールバックします。 .. Note:: このセクションの例では、バックアップターゲットの選択に焦点を当てており、バックアップ方法 `spec.method` は、説明しているスコープと関連がないため考慮されません。 仕組み ^^^^^^ ``prefer-standby`` がターゲットである場合デフォルトの動作、CloudNativePGは次のことを試行します。 1. 最も同期されたスタンバイノードを特定します。 2. そのスタンバイでバックアッププロセスを実行します。 3. 使用可能なスタンバイがない場合、プライマリにフォールバックします。 この戦略により、プライマリのワークロードへの干渉が最小限に抑えられます。 .. Warning:: スタンバイはプライマリと常に最新の状態であるとは限りませんが、最初に使用可能なバックアップから最後にアーカイブされたWALまでの時間連続性では、これは通常無関係です。ベースバックアップは、確かに、PITRを含む復旧操作を開始する開始ポイントを表します。 `pg_basebackup `_ で起こることと同様に、オンラインスタンバイからバックアップする場合、プライマリでWALのスイッチを強制しません。これにより、書き込みアクティビティが低い展開では、短期的に`archive_timeout` がキックインする前に予期しない結果が発生する可能性があります。 プライマリでのバックアップの強制 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 常にプライマリインスタンスでバックアップを実行するには、クラスター構成でバックアップターゲットを\ ``primary`` に明示的に設定します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: [...] spec: backup: target: "primary" .. Warning:: `primary` を**ボリュームスナップショットを使用したコールドバックアップ**のターゲットとして使用する場合、プライマリインスタンスを一時的にシャットダウンする必要があるため、すべての書き込み操作を中断する必要があるため、注意してください。ターゲットを明示的に設定していない場合でも、同じ注意が単一インスタンスのクラスターに適用されます。 クラスター全体のターゲットのオーバーライド ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``Backup`` または\ ``ScheduledBackup`` リソースを使用して、バックアップごとにクラスターレベルのターゲットをオーバーライドできます。次に、オンデマンドバックアップの例を示します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Backup metadata: [...] spec: cluster: name: [...] target: "primary" この例では、クラスターのデフォルトターゲットが\ ``prefer-standby`` であっても、バックアップはプライマリインスタンスから取得されます。 リテンションポリシー -------------------- CloudNativePGは、 **バックアップに依存しないアーキテクチャ** に向けて進化しており、バックアップの責任が外部 **CNPG-Iプラグイン** に委任されます。これらのプラグインは、CloudNativePGのビルトイン機能と範囲を超える、高度なリテンション管理を含む高度なカスタマイズ可能なデータ保護機能を提供することが期待されています。 この移行の一環として、\ ``Cluster`` リソースの\ ``spec.backup.retentionPolicy`` フィールドは **非推奨** であり、将来のリリースでは削除される予定です。 使用可能な保持機能の詳細については、選択したプラグインのドキュメントを参照してください。例 `Retention Policies `_ 。 .. Important:: ユーザーは、使用しているバックアッププラグインが提供する保持メカニズムを信頼することをお勧めします。これにより、使用中のバックアップ方法の柔軟性と一貫性が保証されます。