バックアップ ============ .. Important:: バージョン1.21では、 :ref:`Kubernetes Volume Snapshots <バックアップ>` のネイティブサポートの導入により、CloudNativePGのバックアップおよびリカバリー機能が大幅に変更されました。その時点まで、バックアップとリカバリーはオブジェクトストアでのみ利用できました。このセクションと :ref:`バックアップ リカバリー <バックアップ リカバリー>` を注意深くお読みください CloudNativePG 1.15〜1.20のユーザーである場合に1つ。 PostgreSQLは、ファイルシステムレベルの物理コピーに基づいて、ファーストクラスのバックアップおよびリカバリー機能をネイティブに提供します。これらはミッションクリティカルな運用データベースで15年以上使用され、世界中の組織がPostgresでディザスターリカバリー目標を達成するのを支援してきました。 .. Note:: PostgreSQLでデータベースをバックアップする別の方法があります。`pg_dump` ユーティリティは、物理的バックアップではなく論理バックアップに依存します。ただし、論理バックアップは事業継続のユースケースには適していないため、少なくともまだCloudNativePGの対象になっていません。 `pg_dump` ユーティリティを使用する場合は、 :ref:`Troubleshooting / Emergency backup <バックアップ>` からインスピレーションを得てください。 CloudNativePGでは、各PostgreSQLクラスターのバックアップインフラストラクチャは次のリソースで構成されます。 - **WALアーカイブ** Postgresによって継続的に書き込まれ、データ耐久性のためにアーカイブされるWALファイルトランザクションログを含む場所 - **物理ベースバックアップ** PostgreSQLがデータベースにデータを保存するために使用するすべてのファイルのコピー主に\ ``PGDATA`` およびテーブルスペース WALアーカイブは、現時点ではオブジェクトストアにのみ保存できます。 一方、CloudNativePGは、物理ベースバックアップを保存する2つの方法をサポートしています。 - :ref:`付録A-バックアップ用の共通オブジェクトストア <付録A-バックアップ用の共通オブジェクトストア>` で、tarballsとして - オプションで圧縮 - :ref:`Kubernetes Volume Snapshots <バックアップ>` 上、基になるストレージクラスでサポートされている場合 .. Important:: CloudNativePGでバックアップ戦略を選択する前に、時間をかけてWALアーカイブ、ホットおよびコールドバックアップなどの基本的な概念を理解することが重要です。 WALアーカイブ ------------- PostgreSQLのWALアーカイブは、 **継続的バックアップ** の中心であり、次の理由で基本的なものです。 - **ホットバックアップ** サーバーをシャットダウンせずに、Postgresクラスタープライマリまたはスタンバイのインスタンスから物理ベースのバックアップを取得する可能性。オンラインバックアップとしても知られています - **ポイント インタイム リカバリー** PITR システムで最初に使用可能なベースバックアップから任意の時点で復旧できます。 .. Warning:: WALアーカイブだけでは役に立ちません。物理ベースのバックアップがないと、PostgreSQLクラスターを復元できません。 一般に、WALアーカイブの存在により、PostgreSQLクラスターの復元力が強化され、各インスタンスは、必要に応じてアーカイブから必要なWALファイルを取得できます。通常、WALアーカイブの保持期間は、通常これらのファイルをリサイクルするPostgresインスタンスよりも長くなります。 。 このユースケースは、 WALアーカイブに依存するだけで長距離にわたって同期できるため、 :ref:`レプリカクラスター <レプリカクラスター>` に拡張でき、さまざまなリージョンにわたってディザスターリカバリー目標を拡張できます。 :ref:`configure a WAL archive ` を使用すると、CloudNativePGは、リージョンを超えても、ディザスターリカバリーに5分以下のRPOをすぐに提供します。 .. Important:: 常に本番でWALアーカイブをセットアップすることをお勧めします。通常ステージング環境と開発環境が関係する既知のユースケースがあり、上記の利点はいずれも必要とされず、WALアーカイブは必要ありません。この場合のRPOは、24時間毎日のバックアップまたは無限バックアップなしなどの任意の値です。 コールドおよびホットバックアップ -------------------------------- ホットバックアップは前のセクションで既に定義されています。これらはWALアーカイブの存在を必要とし、最新のデータベース管理システムでは標準です。 **コールドバックアップ** は、オフラインバックアップとしても知られ、代わりに、PostgreSQLインスタンススタンバイまたはプライマリがシャットダウンしたときに取得される物理ベースバックアップです。これらは定義ごとに一貫しており、シャットダウンされた時点のデータベースのスナップショットを表します。 その結果、PostgreSQLインスタンスは、WALアーカイブを必要とせずにコールドバックアップから再起動できますが、利用可能な場合はそれを利用できます前のセクションで強調表示した復旧面のすべての利点を備えています。 RPOが高く1時間または24時間など、保持期間が短い状況では、コールドバックアップは、ディザスターリカバリー計画で検討される実行可能なオプションを表します。 オブジェクトストアまたはボリュームスナップショットどちらを使用しますか? ----------------------------------------------------------------------- CloudNativePGでは、オブジェクトストアベースのバックアップ - 常にWALアーカイブが必要 - ホットバックアップのみをサポート - インクリメンタルコピーをサポートしていません - 差分コピーをサポートしていません 代わりにボリュームスナップショット - WALアーカイブは必要ありませんが、運用環境では常にお勧めします - コールドバックアップのみをサポート現在 - 基になるストレージクラスに応じて、インクリメンタルコピーをサポート - 基になるストレージクラスに応じて、差分コピーをサポート どちらを使用するかは、次を含む特定の要件と環境によって異なります。 - Kubernetesクラスターでの実行可能なオブジェクトストアソリューションの可用性 - ボリュームスナップショットをサポートする信頼できるストレージクラスの可用性 - データベースのサイズ オブジェクトストアの場合、データベースが大きくなると、バックアップ、そして最も重要なことに、リカバリ手順に時間がかかります後者はRTOに影響します。超大規模データベースVLDBが存在する場合、一般的なアドバイスは、コピーオンライトのおかげで、より速いリカバリを提供するため、ボリュームスナップショットに依存することです - データのモビリティと、別のリージョンまたはその後のリージョンのセカンダリの場所にバックアップファイルを保存または中継する可能性 - その他の要素、主に基になるストレージソリューションへの信頼と精通に基づいています 以下の概要表は、物理ベースバックアップの保存に使用可能な2つの方法の主な違いの一部を強調表示しています。 .. csv-table:: :header: "",Object store,Volume Snapshots :widths: 12,25,15 :align: left :class: longtable **WAL archiving** ,Required,Recommended (1) **Cold backup** ,𐄂,✓ **Hot backup** ,✓,𐄂 (2) **Incremental copy** ,𐄂,✓ (3) **Differential copy** ,𐄂,✓ (3) **Backup from a standby** ,✓,✓ **Snapshot recovery** ,𐄂 (4),✓ **Point In Time Recovery (PITR)** ,✓,Requires WAL archive **Underlying technology** ,Barman Cloud,Kubernetes API 上記の表の注意事項については、以下の説明を参照してください。 > > 1.WALアーカイブはオブジェクトストア上にある必要があります。 2.ホットバックアップはボリュームスナップショットではまだ利用できず、バージョン1.22で予定されています。ただし、コールドバックアップがフェンシングによって取得されることを考慮すると、一時的にスタンバイ、この操作は書き込みアプリケーションのダウンタイムを誘発しません。3. PostgreSQLボリュームの基になるストレージクラスでサポートされている場合4. スナップショットリカバリーは、次を使用してエミュレートできます。 ``bootstrap.recovery.recoveryTarget.targetImmediate`` オプション スケジュールされたバックアップ ------------------------------ スケジュールされたバックアップは、CloudNativePGでバックアップ戦略を構成するための推奨される方法です。これらは\ ``ScheduledBackup`` リソースによって管理されます。 .. Note:: :ref:`ScheduledBackupSpec {postgresql-cnpg-io-v1-ScheduledBackupSpec} ` を参照してください。 オプションの完全なリストについては、APIリファレンスを参照してください。 ``schedule`` フィールドでは、 `Go `cron` package format `_ で表現される秒を含む *6期間cronスケジュール* 仕様を定義できます。 .. Warning:: このフォーマットは`seconds` フィールドも受け入れます。Unix/Linuxシステムの`crontab` フォーマットとは異なることに注意してください。 これは、スケジュールされたバックアップの例です。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: ScheduledBackup metadata: name: backup-example spec: schedule: "0 0 0 ** *" backupOwnerReference: self cluster: name: pg-backup 上記の例では、スケジュールで秒、分、および時間を指定する一方、日、月、曜日にすべてを意味するワイルドカードを指定するため、毎日午前0時にバックアップをスケジュールします。 Kubernetes CronJobでは、秒が含まれないため、同等の式は\ ``0 0 ** *`` になります。 .. Hint:: バックアップ頻度は、完全またはポイントインタイム復旧操作が必要なディザスターの発生後の復旧時間オブジェクトRTOに影響を与える可能性があります。私たちのアドバイスは、バックアップをリカバリーし、スクラッチからのリカバリーにかかる時間を測定することにより、バックアップを定期的にテストして、RTOの予測可能性を調整することです。リカバリ時間は、ベースバックアップのサイズと、リカバリ中にアーカイブから取得して再生する必要があるWALファイルの量に影響されます。WALアーカイブは、PostgreSQLでの継続的なバックアップを可能にするものであることに注意してください。私たちの経験に基づいて、ほとんどの場合、毎週のベースバックアップで十分です。ただし、1日1回より頻繁にバックアップをスケジュールすることは非常にまれです。 ``.spec.method`` 属性、デフォルトでは\ ``barmanObjectStore`` に設定を介して、定義されたオブジェクトストアまたはボリュームスナップショットのバックアップをスケジュールするかどうかを選択できます。 :ref:`オブジェクトストアまたはボリュームスナップショットどちらを使用しますか? <オブジェクトストアまたはボリュームスナップショットどちらを使用しますか?>` を適切に定義している場合 クラスターの\ ``backup`` スタンザでは、ボリュームスナップショットのベースバックアップのスケジュールを開始するように\ ``method: volumeSnapshot`` を設定できます。 スケジュールされたバックアップは、必要に応じて ``.spec.suspend: true`` を設定することにより一時停止できます。これにより、オプションが削除されるか\ ``false`` に設定されるまで、新しいバックアップはスケジュールされなくなります。 ScheduledBackupリソースが作成されたらすぐにバックアップを発行したい場合は、\ ``.spec.immediate: true`` を設定できます。 .. Note:: `.spec.backupOwnerReference` は、作成されたバックアップリソース内にどのownerReferenceを配置するかを示します。 - *none:* 作成されたバックアップオブジェクトの所有者参照なしフィールドが導入される前と同じ動作 オンデマンド バックアップ ------------------------- .. Note:: :ref:`BackupSpec {postgresql-cnpg-io-v1-BackupSpec} ` を参照してください。 オプションの完全なリストについては、APIリファレンスを参照してください。 新しいバックアップを要求するには、次のような新しい\ ``Backup`` リソースを作成する必要があります。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Backup metadata: name: backup-example spec: method: barmanObjectStore cluster: name: pg-backup この場合、オペレーターはクラスターのオーケストレーションを開始し、\ ``barman-cloud-backup`` を使用してオブジェクトストアで必要なバックアップを取得します。通常の\ ``kubectl describe backup `` コマンドを使用して、バックアップステータスを確認できます。 .. code:: text Name: backup-example Namespace: default Labels: Annotations: API Version: postgresql.cnpg.io/v1 Kind: Backup Metadata: Creation Timestamp: 2020-10-26T13:57:40Z Self Link: /apis/postgresql.cnpg.io/v1/namespaces/default/backups/backup-example UID: ad5f855c-2ffd-454a-a157-900d5f1f6584 Spec: Cluster: Name: pg-backup Status: Phase: running Started At: 2020-10-26T13:57:40Z Events: バックアップが完了すると、フェーズは次の例のように\ ``completed`` になります。 .. code:: text Name: backup-example Namespace: default Labels: Annotations: API Version: postgresql.cnpg.io/v1 Kind: Backup Metadata: Creation Timestamp: 2020-10-26T13:57:40Z Self Link: /apis/postgresql.cnpg.io/v1/namespaces/default/backups/backup-example UID: ad5f855c-2ffd-454a-a157-900d5f1f6584 Spec: Cluster: Name: pg-backup Status: Backup Id: 20201026T135740 Destination Path: s3://backups/ Endpoint URL: http://minio:9000 Phase: completed s3Credentials: Access Key Id: Key: ACCESS_KEY_ID Name: minio Secret Access Key: Key: ACCESS_SECRET_KEY Name: minio Server Name: pg-backup Started At: 2020-10-26T13:57:40Z Stopped At: 2020-10-26T13:57:44Z Events: !!!重要 この機能は、スーパーユーザーとアプリケーションユーザーのシークレットをバックアップしません。シークレットは、Kubernetesクラスターの標準のバックアップ手順の一部としてバックアップされることになっています。 スタンバイからのバックアップ ---------------------------- ベースバックアップを取るには、ディスク上のPostgreSQLインスタンスのデータコンテンツ全体をスクレイピングする必要があります、その結果、データベースの実際のワークロードとのI/O競合が発生する可能性があります。 このため、CloudNativePGでは、 PostgreSQLで直接利用可能な機能 **スタンバイからのバックアップ** を利用できます。 デフォルトでは、バックアップは\ ``Cluster`` の最もアライメントの高いレプリカで実行されます。使用可能なレプリカがない場合、バックアップはプライマリインスタンスで実行されます。 .. Note:: スタンバイはプライマリと常に最新の状態であるとは限りませんが、最初に使用可能なバックアップから最後にアーカイブされたWALまでの時間連続性では、これは通常無関係です。ベースバックアップは、確かに、PITRを含む復旧操作を開始する開始ポイントを表します。 `pg_basebackup `_ で起こることと同様に、オンラインスタンバイからバックアップする場合、プライマリでWALのスイッチを強制しません。これにより、書き込みアクティビティが低い展開では、短期的に`archive_timeout` がキックインする前に予期しない結果が発生する可能性があります。 常にプライマリでバックアップを実行したい場合は、以下の例に示すようにバックアップターゲットを\ ``primary`` に設定できます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: [...] spec: backup: target: "primary" .. Warning:: ボリュームスナップショットを使用してコールドバックアップを実行するときは、ターゲットをプライマリに設定するように注意してください。これにより、スナップショットの取得に必要な時間プライマリがシャットダウンし、書き込み操作に影響します。これは、プライマリをターゲットとして明示的に設定していない場合でも、単一インスタンスのクラスターでコールドバックアップを取得する場合にも適用されます。 バックアップターゲットが\ ``prefer-standby`` に設定されている場合、このようなポリシーは、バックアップが最新の使用可能なセカンダリインスタンスで実行されるか、他のインスタンスが使用できない場合はプライマリインスタンスで実行されます。 デフォルトでは、特に指定しない限り、ターゲットはスタンバイからバックアップを取得するように自動的に設定されます。 ``Cluster`` で指定されたバックアップターゲットは、次の例のように、 ``Backup`` および\ ``ScheduledBackup`` タイプでオーバーライドできます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Backup metadata: [...] spec: cluster: name: [...] target: "primary" 前の例では、\ ``Cluster`` がレプリカを優先するように設定されている場合でも、CloudNativePGは常にプライマリインスタンスを選択します。