Appendix A - Backup on volume snapshots ======================================= .. raw:: html .. Note:: サポートされているすべてのサービスのリストについては、Kubernetesの公式ドキュメントを参照してください `Container Storage Interface (CSI) drivers `_ スナップショット機能を提供します。 　 CloudNativePGは、完全に宣言的な方法で、バックアップとリカバリー操作の両方にKubernetesネイティブボリュームスナップショットAPIを直接利用するデータベースオペレーターの最初の既知のケースの1つです。 標準のボリュームスナップショットについて ---------------------------------------- ボリュームスナップショットは `Kubernetes 1.12 (2018) as alpha `_ で最初に導入され、 `beta in 1.17 (2019) `_ 、および `moved to GA in 1.20 (2020) `_ に昇格しました。安定して広く利用可能な標準になり、3つのカスタムリソース定義\ ``VolumeSnapshot`` 、\ ``VolumeSnapshotContent`` 、\ ``VolumeSnapshotClass`` を提供します。 このKubernetes機能は、次の汎用インターフェイスを定義します。 - PVCから始まる新しいボリュームスナップショットの作成 - 既存のスナップショットの削除 - スナップショットからの新しいボリュームの作成 Kubernetesは、実際の実装を基になるCSIドライバーに委任しますそれらのすべてがボリュームスナップショットをサポートしているわけではありません。通常、ボリュームスナップショットを提供するストレージクラスは、 **アプリケーションの透過的な方法でのインクリメンタルおよび差分ブロックレベルのバックアップ** をサポートします。これにより、スナップショットのクラスター間の可用性を含む、スタックの複雑さと独立した管理を委任できます。 要件 ---- ボリュームスナップショットがCloudNativePGクラスターで動作するには、PostgreSQLボリュームつまり ``storage`` および\ ``walStorage`` セクションの動的プロビジョニングに使用される各ストレージクラスがボリュームスナップショットをサポートしていることを確認する必要があります。 手順はストレージクラスごとに異なるため、Kubernetesシステムに展開した特定のストレージクラスと関連するCSIドライバーのドキュメントを参照してください。 通常、それは `VolumeSnapshotClass `_ です 特定のストレージクラスの永続ボリュームからスナップショットを取得し、\ ``VolumeSnapshot`` および\ ``VolumeSnapshotContent`` リソースとして管理できることを保証します。 .. Note:: ボリュームスナップショットがサポートされていることをサードパーティベンダーに確認するのはあなたの責任です。 CloudNativePGは、この問題に関してKubernetes APIとのみ対話し、特定のCSIドライバーごとにストレージレベルでの問題をサポートすることはできません。 　 ボリュームスナップショットバックアップを構成する方法 ---------------------------------------------------- CloudNativePGでは、 ``backup.volumeSnapshot`` スタンザを介したボリュームスナップショットバックアップ用に特定のPostgresクラスターを構成できます。 .. Note:: :ref:`VolumeSnapshotConfiguration ` を参照してください。 オプションの完全なリストについては、APIリファレンスを参照してください。 　 ボリュームスナップショットを使用した一般的な例PGDATAとWALが同じストレージクラスを共有すると仮定した場合、次のとおりです。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: snapshot-cluster spec: instances: 3 storage: storageClass: @STORAGE_CLASS@ size: 10Gi walStorage: storageClass: @STORAGE_CLASS@ size: 10Gi backup: # Volume snapshot backups volumeSnapshot: className: @VOLUME_SNAPSHOT_CLASS_NAME@ plugins: - name: barman-cloud.cloudnative-pg.io isWALArchiver: true parameters: barmanObjectName: @OBJECTSTORE_NAME@ ご覧のとおり、 ``backup`` セクションには、 ``volumeSnapshot`` スタンザボリュームスナップショットの物理ベースバックアップの制御と ``plugins`` スタンザ :ref:`WALアーカイブ ` の制御 の両方が含まれています。 .. Note:: `plugin` を定義すると、ボリュームスナップショットとプラグインバックアップ戦略の両方を同時に使用して物理的バックアップを取ることができます。 　 ``volumeSnapshot.className`` オプションを使用すると、PostgreSQLクラスターで定義したすべてのストレージボリュームに使用されるデフォルトの\ ``VolumeSnapshotClass`` オブジェクトを参照できます。 .. Note:: `PGDATA` およびWALファイルに別のストレージクラスを使用している場合、 `walClassName` オプションデフォルトで`className` と同じ値を介してそのボリュームに別個の`VolumeSnapshotClass` を指定できます。 　 ボリュームスナップショットバックアップ用にクラスターを定義したら、このようなバックアップを定期的に要求する\ ``ScheduledBackup`` リソースを定義する必要があります。 ホットおよびコールドバックアップ -------------------------------- .. Warning:: :ref:`backup document ` で述べたように、プライマリをターゲットとするように明示的に設定されたコールドスナップショットは、バックアップ中にプライマリがフェンスされ、この期間中のクラスターは読み取り専用になります。安全のため、フェンスされたインスタンスが既に含まれているクラスターでは、コールドスナップショットは拒否されます。 　 デフォルトでは、CloudNativePGは `PostgreSQL defaults of the low-level API for base backups `_ を使用して、ボリュームスナップショットのオンライン/ホットバックアップを要求します。 - バックアップ手順の開始時に、即時チェックポイントを要求しません - バックアップ手順を終了するときに、WALアーカイバーがバックアップの最後のセグメントをアーカイブするのを待機します .. Note:: デフォルト値は、ほとんどの実稼働環境に適しています。ホットバックアップは一貫性があり、スナップショットリカバリーを実行するために使用できます。バックアップの開始から一時レプリケーションスロットを介してWALの保持を保証します。ただし、そのためにはコールドバックアップに依存することをお勧めします。 　 ``Cluster`` リソースの\ ``.spec.backup.volumeSnapshot`` スタンザの次のオプションを使用して、デフォルトの動作を明示的に変更できます。 - ``online`` ``true`` デフォルトまたは\ ``false`` を値として受け入れます - ``onlineConfiguration.immediateCheckpoint`` バックアップ手順を開始する前に、即時チェックポイントを要求するかどうか。技術的には、PostgreSQLの\ ``pg_backup_start`` /``pg_start_backup()`` ファンクションに渡す\ ``fast`` 引数に対応し、\ ``true`` デフォルトまたは\ ``false`` を受け入れます - ``onlineConfiguration.waitForArchive`` アーカイバーがバックアップの最後のセグメントを処理するまで待機するかどうか。技術的には、PostgreSQLの\ ``pg_backup_stop`` /``pg_stop_backup()`` ファンクションに渡す\ ``wait_for_archive`` 引数に対応し、\ ``true`` デフォルトまたは\ ``false`` を受け入れます デフォルトでコールドバックアップを取得するようにPostgresクラスターのデフォルト動作を変更する場合、次のようにマニフェストに\ ``online: false`` オプションを追加するだけです。 .. code:: yaml # ... backup: volumeSnapshot: online: false # ... 代わりに、デフォルトの動作として即時チェックポイントを要求する場合、このセクションを追加できます。 .. code:: yaml # ... backup: volumeSnapshot: online: true onlineConfiguration: immediateCheckpoint: true # ... デフォルト動作のオーバーライド ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``Backup`` または\ ``ScheduledBackup`` オブジェクトの\ ``online`` および必要に応じて\ ``onlineConfiguration`` に別の値を設定することにより、クラスターリソースで定義されたデフォルトの動作を変更できます。 たとえば、オンデマンドのコールドバックアップを発行する場合、\ ``.spec.online: false`` を使用して\ ``Backup`` オブジェクトを作成できます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Backup metadata: name: snapshot-cluster-cold-backup-example spec: cluster: name: snapshot-cluster method: volumeSnapshot online: false 同様に、 ScheduledBackupの場合 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: ScheduledBackup metadata: name: snapshot-cluster-cold-backup-example spec: schedule: "0 0 0 ** *" backupOwnerReference: self cluster: name: snapshot-cluster method: volumeSnapshot online: false ボリュームスナップショットオブジェクトの永続化 ---------------------------------------------- デフォルトでは、 CloudNativePGによって作成された\ ``VolumeSnapshot`` オブジェクトは、それらを生成した\ ``Backup`` オブジェクトまたはそれらが参照する\ ``Cluster`` を削除した後も保持されます。このような動作は、次の値を受け入れる\ ``.spec.backup.volumeSnapshot.snapshotOwnerReference`` オプションによって制御されます。 - ``none`` 所有権が設定されていません。\ ``Backup`` および/または\ ``Cluster`` リソースが削除された後も\ ``VolumeSnapshot`` オブジェクトが持続することを意味します - ``backup`` ``VolumeSnapshot`` オブジェクトは、それを生成した\ ``Backup`` リソースが所有しており、バックアップオブジェクトが削除されると、ボリュームスナップショットも削除されます - ``cluster`` ``VolumeSnapshot`` オブジェクトは、バックアップされた\ ``Cluster`` リソースが所有しており、Postgresクラスターが削除されると、ボリュームスナップショットも削除されます ``VolumeSnapshot`` が削除される場合、 ``VolumeSnapshotContent`` で指定された\ ``deletionPolicy`` が評価されます。 - ``Retain`` に設定されている場合、\ ``VolumeSnapshotContent`` オブジェクトは保持されます - ``Delete`` に設定されている場合、\ ``VolumeSnapshotContent`` オブジェクトも削除されます .. Warning:: `VolumeSnapshotContent` オブジェクトは、バックアップと参照するクラスターに関するすべての情報を保持していません `VolumeSnapshot` オブジェクトに含まれる注釈やラベルなど。可能ですが、この種のオブジェクトのみからの復元は簡単ではない場合があります。このため、Kubernetesレベルのデータ保護ソリューションを使用する場合でも、常に`VolumeSnapshot` 定義をバックアップすることをお勧めします。 　 ``VolumeSnapshotContent`` の値は、対応する\ ``VolumeSnapshotClass`` 定義で設定された\ ``deletionPolicy`` によって決定されます。これは、 ``.spec.backup.volumeSnapshot.className`` オプションで参照されます。 `Kubernetes documentation on Volume Snapshot Classes `_ を参照してください。 この標準の動作の詳細については、 バックアップボリュームのスナップショットの期限 ---------------------------------------------- CloudNativePGは、ボリュームスナップショット方法を使用したバックアップをサポートしています。一部の環境では、ボリュームスナップショットで再試行可能な一時的な問題が発生する場合があります。 ``backup.cnpg.io/volumeSnapshotDeadline`` アノテーションは、バックアップを失敗としてマーキングする前に、CloudNativePGが回復可能なエラーの再試行を継続する時間を定義します。 ``backup.cnpg.io/volumeSnapshotDeadline`` アノテーションは、 ``Backup`` および\ ``ScheduledBackup`` リソースの両方に追加できます。 ``ScheduledBackup`` リソースの場合、このアノテーションは、スケジュールから作成された\ ``Backup`` リソースに自動的に継承されます。 指定しない場合、デフォルトの再試行期限は **10分** です。 エラー処理 ^^^^^^^^^^ ボリュームスナップショット操作中に再試行可能なエラーが発生した場合 1. CloudNativePGは、最初のエラーの時間を記録します。 2. システムは **10秒** ごとに操作を再試行します。 3. エラーが指定された期限またはデフォルトの10分を超えて続く場合、バックアップは **失敗** としてマークされます。 再試行可能なエラー ^^^^^^^^^^^^^^^^^^ CloudNativePGは、次の種類のエラーを再試行可能として扱います。 - **サーバータイムアウトエラー** HTTP 408、429、500、502、503、504 - **競合** オプティミスティックロックエラー - **内部エラー** - **コンテキスト期限超過エラー** - **CSIスナップショットコントローラからのタイムアウトエラー** 例 ^^ 次のようにして、アノテーションを\ ``ScheduledBackup`` リソースに追加できます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: ScheduledBackup metadata: name: daily-backup-schedule annotations: backup.cnpg.io/volumeSnapshotDeadline: "20" spec: schedule: "0 0 ** *" backupOwnerReference: self method: volumeSnapshot # other configuration... アノテーションを使用して\ ``ScheduledBackup`` を定義すると、このスケジュールから作成される\ ``Backup`` リソースは、指定されたタイムアウト値を自動的に継承します。 次の例では、スケジュールから作成されたすべてのバックアップには、回復可能なスナップショットエラーを再試行するために30分のタイムアウトがあります。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: ScheduledBackup metadata: name: weekly-backup annotations: backup.cnpg.io/volumeSnapshotDeadline: "30" spec: schedule: "0 0 ** 0" # Weekly backup on Sunday method: volumeSnapshot cluster: name: my-postgresql-cluster または、アノテーションを\ ``Backup`` リソースに直接追加できます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Backup metadata: name: my-backup annotations: backup.cnpg.io/volumeSnapshotDeadline: "15" spec: method: volumeSnapshot # other backup configuration... ボリュームスナップショットバックアップの例 ------------------------------------------ 次の例は、 ``ebs-sc`` ストレージクラスと\ ``csi-aws-vsc`` ボリュームスナップショットクラスを使用して、AWSのEKSクラスターでボリュームスナップショットベースバックアップを構成する方法を示しています。 .. Note:: 例のテストに興味がある場合は、ストレージクラスとスナップショットクラスのインストールプロセスの詳細な手順については、 `Volume Snapshots `_ を読んでください。 　 次のマニフェストは、ボリュームスナップショットに使用する準備ができ、サービスアカウントIRSAのIAMロールを介してS3バケットにWALアーカイブを保存するを作成します :ref:`AWS S3 ` を参照してください。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: hendrix spec: instances: 3 storage: storageClass: ebs-sc size: 10Gi walStorage: storageClass: ebs-sc size: 10Gi backup: volumeSnapshot: className: csi-aws-vsc plugins: - name: barman-cloud.cloudnative-pg.io isWALArchiver: true parameters: barmanObjectName: @OBJECTSTORE_NAME@ serviceAccountTemplate: metadata: annotations: eks.amazonaws.com/role-arn: "@ARN@" - -- apiVersion: postgresql.cnpg.io/v1 kind: ScheduledBackup metadata: name: hendrix-vs-backup spec: cluster: name: hendrix method: volumeSnapshot schedule: 0 0 0 ** * backupOwnerReference: cluster immediate: true 最後のリソースは、深夜に毎日のボリュームスナップショットバックアップを定義し、クラスターが作成された直後に1つを要求します。