このページでは、AlloyDB Omni Kubernetes Operator を使用して AlloyDB Omni データをバックアップおよび復元する方法について説明します。これには、マニフェスト ファイルと kubectl コマンドライン ツールを使用して Kubernetes クラスタを更新する方法に関する基本的な知識が必要です。Kubernetes クラスタに AlloyDB Omni をインストールして実行する方法については、Kubernetes に AlloyDB Omni をインストールするをご覧ください。
AlloyDB Omni の継続的なバックアップと復元を有効にするには、データベース クラスタごとにバックアップ プランを作成する必要があります。バックアップは、backupPlan リソースで定義されたバックアップ スケジュールに基づいて行われます。バックアップ プランでバックアップ スケジュールが定義されていない場合、デフォルトでは継続的なバックアップが毎日実行されます。復元期間内の任意のタイムスタンプから、秒単位でバックアップを復元またはクローニングできます。
Kubernetes 以外のデプロイで AlloyDB Omni データをバックアップして復元する方法については、Barman をインストールして構成するをご覧ください。
バックアップを有効にしてスケジュールを設定する
継続的なバックアップは、データベース クラスタのバックアップ プラン リソースを作成すると有効になります。クラスタの継続的なバックアップを有効にするには、データベース クラスタごとに backupPlan リソースを作成する必要があります。このバックアップ プラン リソースは、次のパラメータを定義します。
AlloyDB Omni Operator がバックアップを保存する場所。Kubernetes クラスタのローカル、または Cloud Storage バケットを指定できます。
full、incremental、differentialのバックアップを自動的に作成する複数のバックアップ スケジュールを設定するオプション。このスケジュールは、バックアップ プランを最初に定義するときを含め、いつでも一時停止できます。バックアップ プランを一時停止すると、スケジュール設定されたバックアップは作成されませんが、手動でバックアップを作成することは可能です。バックアップ スケジュールが指定されていない場合、デフォルトは 0 0 * * * になります。この場合、現地時間の午前 0 時に 1 日 1 回のフル バックアップが行われます。
保存されたバックアップの保持期間。最短 1 日から最長 90 日まで設定できます。デフォルト値は 14 です。
データベース クラスタには、それぞれ独自の名前と構成を持つ複数のバックアップ プランを設定できます。データベース クラスタに、異なるバックアップ スケジュールを持つ複数の backupPlan リソースを作成する場合は、バックアップ リソースごとに固有のバックアップ ロケーションを定義する必要があります。
バックアップをローカルに保存するプランを作成する
ローカルに保存するバックアップを有効にするには、次のマニフェストを適用します。
apiVersion: alloydbomni.dbadmin.goog/v1
kind: BackupPlan
metadata:
name: BACKUP_PLAN_NAME
namespace: NAMESPACE
spec:
dbclusterRef: DB_CLUSTER_NAME
backupSchedules:
full: "FULL_CRON_SCHEDULE"
differential: "DIFF_CRON_SCHEDULE"
incremental: "INCR_CRON_SCHEDULE"
backupRetainDays: RETENTION_DAYS
paused: PAUSED_BOOLEAN
次のように置き換えます。
BACKUP_PLAN_NAME: このバックアップ プラン リソースの名前。例:backup-plan-1NAMESPACE: このバックアップ プランの Kubernetes Namespace。データベース クラスタの Namespace と一致する必要があります。DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てたものです。FULL_CRON_SCHEDULE: すべてのデータを含むフル バックアップを作成するバックアップ スケジュール。cron形式で表されます。たとえば、毎週日曜日の 00:00 にフル バックアップを行うには、0 0 * * 0 に設定します。DIFF_CRON_SCHEDULE: 最初のバックアップではフル バックアップを作成するバックアップ スケジュール。その後のバックアップは、データへの変更に基づく差分バックアップで、cron形式で表されます。たとえば、毎週水曜日の 22:00 に差分バックアップを行うには、「0 22 * * 3」に設定します。INCR_CRON_SCHEDULE: 前回のフル バックアップ、差分バックアップ、増分バックアップから変更されたデータを含むバックアップを作成するバックアップ スケジュール。cron形式で表されます。たとえば、毎日 21:00 に増分バックアップを行うには、「0 21 * * *」と設定します。RETENTION_DAYS: AlloyDB Omni Operator がこのバックアップを保持する日数。1~90の整数を指定する必要があります。デフォルト値は14です。PAUSED_BOOLEAN: バックアップ プランを一時停止するかどうかを指定します。次のいずれかの値を指定します。true: バックアップが一時停止され、スケジュール設定されたバックアップは作成されません。false: AlloyDB Omni Operator は、cronScheduleで指定されたスケジュールに従ってバックアップを作成します。明示的にtrueに設定されていない場合のデフォルト値です。
デフォルト値は
falseです。
Cloud Storage にバックアップを保存するプランを作成する
Cloud Storage に保存するバックアップを有効にする手順は次のとおりです。
Cloud Storage バケットを作成します。このバケットに割り当てた名前をメモしておきます。この名前は後の手順で必要になります。
バックアップをバケットに追加するためのサービス アカウントを作成します。
サービス アカウントに
storage.objectAdminIdentity and Access Management ロールを付与します。サービス アカウントのキーを作成します。これにより、秘密鍵がローカル環境にダウンロードされます。
ダウンロードした鍵ファイルの名前を
key.jsonに変更します。秘密鍵を含む Kubernetes Secret を作成します。
kubectl create secret generic SECRET_NAME --from-file=KEY_PATH -n NAMESPACE次のように置き換えます。
SECRET_NAME: 作成する Kubernetes Secret の名前(例:gcs-key)。KEY_PATH: 前の手順でダウンロードしたkey.jsonファイルのローカル ファイル システムパス。NAMESPACE: データベース クラスタの Namespace。
次のマニフェストを適用します。
apiVersion: alloydbomni.dbadmin.goog/v1 kind: BackupPlan metadata: name: BACKUP_PLAN_NAME namespace: NAMESPACE spec: dbclusterRef: DB_CLUSTER_NAME backupSchedules: full: "FULL_CRON_SCHEDULE" differential: "DIFF_CRON_SCHEDULE" incremental: "INCR_CRON_SCHEDULE" backupRetainDays: RETENTION_DAYS paused: PAUSED_BOOLEAN backupLocation: type: GCS gcsOptions: bucket: BUCKET_URL key: BACKUP_PATH secretRef: name: SECRET_NAME namespace: NAMESPACE次のように置き換えます。
BACKUP_PLAN_NAME: このバックアップ プラン リソースの名前。例:backup-plan-1NAMESPACE: このバックアップ プランの Kubernetes Namespace。データベース クラスタの Namespace と一致する必要があります。DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てたものです。FULL_CRON_SCHEDULE: すべてのデータを含むフル バックアップを作成するバックアップ スケジュール。cron形式で表されます。たとえば、毎週日曜日の 00:00 にフル バックアップを行うには、0 0 * * 0 に設定します。DIFF_CRON_SCHEDULE: 最初のバックアップではフル バックアップを作成するバックアップ スケジュール。その後のバックアップは、データへの変更に基づく差分バックアップで、cron形式で表されます。たとえば、毎週水曜日の 22:00 に差分バックアップを行うには、「0 22 * * 3」に設定します。INCR_CRON_SCHEDULE: 前回のフル バックアップ、差分バックアップ、増分バックアップから変更されたデータを含むバックアップを作成するバックアップ スケジュール。cron形式で表されます。たとえば、毎日 21:00 に増分バックアップを行うには、「0 21 * * *」と設定します。RETENTION_DAYS: AlloyDB Omni Operator がこのバックアップを保持する日数。1~90の整数を指定する必要があります。デフォルト値は14です。PAUSED_BOOLEAN: バックアップ プランを一時停止するかどうかを指定します。次のいずれかの値を指定します。true: バックアップが一時停止され、スケジュール設定されたバックアップは作成されません。false: AlloyDB Omni Operator は、cronScheduleで指定されたスケジュールに従ってバックアップを作成します。明示的にtrueに設定されていない場合のデフォルト値です。
デフォルト値は
falseです。
BUCKET_URL: 前の手順で作成した Cloud Storage バケットの名前。これはバケットの完全な URL ではありません。バケット名の前にgs://を付けないでください。BACKUP_PATH: AlloyDB Omni Operator がバックアップを書き込むディレクトリのパス(Cloud Storage バケット内)。パスは絶対パスで、/で始める必要があります。SECRET_NAME: 前の手順で作成した Kubernetes Secret に選択した名前。
バックアップを手動で作成する
データベース クラスタにすでに適用されているバックアップ プランを使用して、バックアップ リソースを手動でいつでも作成できます。AlloyDB Omni Operator は、選択したバックアップ プランのストレージ ロケーションと保持期間を新しい手動バックアップに適用します。
バックアップを手動で作成するには、次のマニフェストを適用します。
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Backup
metadata:
name: BACKUP_NAME
namespace: NAMESPACE
spec:
dbclusterRef: DB_CLUSTER_NAME
backupPlanRef: BACKUP_PLAN_NAME
manual: true
physicalBackupSpec:
backupType: BACKUP_TYPE
次のように置き換えます。
BACKUP_NAME: このバックアップの名前。例:backup-1NAMESPACE: この復元の Kubernetes Namespace。データベース クラスタの Namespace と一致する必要があります。BACKUP_PLAN_NAME: このバックアップが属するバックアップ プラン リソースの名前。バックアップ プランの作成時に選択した名前と一致している必要があります。DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てたものです。BACKUP_TYPE: 作成する手動バックアップのタイプを指定します。次の値のいずれかを選択します。full: すべてのデータを含むフル バックアップを作成します。diff: 最後のフル バックアップに依存する差分バックアップを作成します。その後のバックアップは、データの変更に基づく差分バックアップになります。incr: 前回のフル バックアップまたは差分バックアップに依存する増分バックアップを作成し、前回のフル バックアップまたは差分バックアップから変更されたデータを含めます。
バックアップのモニタリングと一覧表示
バックアップ プランとバックアップはすべて Kubernetes クラスタのリソースです。この情報を表示するには、kubectl
get コマンドを使用します。
バックアップ プランの概要を表示する
データベース クラスタのバックアップ プランに関する情報を表示するには、次のコマンドを実行します。
kubectl get backupplan.alloydbomni.dbadmin.goog -n NAMESPACENAMESPACE は、データベース クラスタの Namespace に置き換えます。
出力は次のようになります。
NAME PHASE LASTBACKUPTIME NEXTBACKUPTIME
backup-plan-prod Ready 2023-10-26T17:26:43Z 2023-10-27T00:00:00Z
バックアップのリストを表示する
データベース クラスタで使用可能なバックアップのリストを表示するには、次のコマンドを実行します。
kubectl get backup.alloydbomni.dbadmin.goog -n NAMESPACENAMESPACE は、データベース クラスタの Namespace に置き換えます。
出力は次のようになります。
NAME PHASE COMPLETETIME
backup-plan-prod-20231026172643 Succeeded 2023-10-26T17:26:53Z
manual-backup-1 Succeeded 2023-10-26T18:15:27Z
manual-backup-2 InProgress
出力テーブルの各行は、次の属性を持つバックアップ リソースを表します。
- バックアップの名前。
- バックアップの状態。
Succeededは、バックアップから復元する準備ができている状態を示します。 - バックアップ作成時のタイムスタンプ。
バックアップから復元する
AlloyDB では、個々のバックアップの復元や、特定の時点のバックアップを使用したクラスタのクローニングを行えます。
名前付きバックアップから復元する
バックアップから復元し、データベース クラスタ内のデータをバックアップ内のデータに置き換える手順は次のとおりです。
フェーズが
Succeededのすべてのバックアップのリストを表示します。kubectl get backup.alloydbomni.dbadmin.goog -n NAMESPACE | grep SucceededNAMESPACEは、データベース クラスタの Namespace に置き換えます。有効なバックアップ候補が 1 つ以上存在する場合、出力は次のようになります。
backup-plan-prod-20231026172643 Succeeded 2023-10-26T17:26:53Z manual-backup-1 Succeeded 2023-10-26T18:15:27Z前の手順で復元元のバックアップとして表示されたバックアップのいずれかを選択します。名前をメモします。これは次のステップで使用します。
次のマニフェストを適用します。
apiVersion: alloydbomni.dbadmin.goog/v1 kind: Restore metadata: name: RESTORE_NAME namespace: NAMESPACE spec: sourceDBCluster: DB_CLUSTER_NAME backup: BACKUP_NAME次のように置き換えます。
RESTORE_NAME: このマニフェストが作成するデータ復元リソースで使用する名前。例:
restore-1DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てたものです。
BACKUP_NAME: 前の手順で選択したバックアップの名前。
クラスタのクローンを特定の時点で作成する
AlloyDB Omni Operator を使用すると、復元期間内の任意の時点からクラスタのデータをクローニングできます。復元期間の長さは、そのまま保持期間によって決まります。
たとえば、保持期間が 14 日に設定されている場合、14 日より古いデータは復元できません。復元期間内の任意の時点に復元できます。AlloyDB Omni Operator は、指定された値より 1 日長くバックアップとログを保持します。
復元期間をモニタリングして、復元ポイントを特定します。
kubectl get backupplan.alloydbomni.dbadmin.goog BACKUP_NAME -n NAMESPACE -o json | jq .status.recoveryWindowレスポンスの例を次に示します。
recoveryWindow: begin: "2024-01-31T02:54:35Z"復元リソースでは、RFC 3339 タイムスタンプ形式のタイムスタンプ値が使用されます。
次の復元リソース マニフェストを作成して適用します。
apiVersion: alloydbomni.dbadmin.goog/v1 kind: Restore metadata: name: RESTORE_NAME namespace: NAMESPACE spec: sourceDBCluster: DB_CLUSTER_NAME pointInTime: "DATE_AND_TIME_STAMP" clonedDBClusterConfig: dbclusterName: NEW_DB_CLUSTER_NAME次のように置き換えます。
RESTORE_NAME: このマニフェストが作成するデータ復元リソースで使用する名前。例:
restore-1DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てたものです。
DATE_AND_TIME_STAMP: 復元元の継続的なバックアップの分単位の RFC 3339 タイムスタンプ。例:
2024-03-05T15:32:10ZNEW_DB_CLUSTER_NAME: 新しいデータベース クラスタの名前。
復元ステータスを表示する
復元オペレーションの進行状況を表示します。
kubectl get restore.alloydbomni.dbadmin.goog -n NAMESPACENAMESPACEは、データベース クラスタの Namespace に置き換えます。コマンドを継続的に実行するには、
-Awフラグを追加します。出力は次のようになります。
NAME PHASE COMPLETETIME RESTOREDPOINTINTIME restore-1 RestoreInProgress出力テーブルの
PHASE列の値がProvisionSucceededになったら、復元は完了です。復元またはクローンを作成したデータベース クラスタがオンラインになるまでの進行状況を確認します。
kubectl get dbclusters -A -n NAMESPACENAMESPACEは、データベース クラスタの Namespace に置き換えます。コマンドを継続的に実行するには、
-Awフラグを追加します。出力は次のようになります。
NAMESPACE NAME PRIMARYENDPOINT PRIMARYPHASE DBCLUSTERPHASE default db-cluster-1 10.128.0.55 Ready DBClusterReady出力テーブルの
DBCLUSTERPHASE列の値がDBClusterReadyになれば、復元またはクローンを作成したデータベース クラスタは使用できる状態です。
バックアップを削除する
通常、バックアップを手動で削除する必要はありません。AlloyDB Omni Operator は、バックアップ プランの作成時に指定した保持期間より古いバックアップを自動的に削除します。
バックアップを手動で削除する場合は、バックアップが次の要件を満たしている必要があります。
そのバックアップが、バックアップ プランに保存されている唯一のバックアップではないこと。AlloyDB Omni Operator では、バックアップ プランごとに少なくとも 1 つのバックアップが存在している必要があります。
そのバックアップに依存するほかのバックアップがないこと。たとえば、そのバックアップに依存する差分バックアップや増分バックアップがあるフル バックアップや、そのバックアップに依存する差分バックアップがある増分バックアップなどが該当します。
バックアップを削除するには、次のコマンドを実行します。
kubectl delete backup.alloydbomni.dbadmin.goog/BACKUP_NAME -n NAMESPACE次のように置き換えます。
BACKUP_NAME: 削除するバックアップの名前。NAMESPACE: データベース クラスタの名前空間。
バックアップ プランを更新する
すべてのバックアップ プランは Kubernetes リソースです。構成を更新するには、次のいずれかの操作を行います。
バックアップ プランのマニフェスト ファイルを編集して再適用する。
kubectl patchコマンドを使用する。
たとえば、実行中のバックアップ プランを一時停止するには、マニフェストの paused 属性を true に変更してから、マニフェストを再適用します。
バックアップ プランを削除する
バックアップ プランを削除して、そのバックアップ リソースをすべて削除するには、次のコマンドを実行します。
kubectl delete backupplan.alloydbomni.dbadmin.goog/BACKUP_PLAN_NAME -n NAMESPACE次のように置き換えます。
BACKUP_PLAN_NAME: 削除するバックアップ プランの名前。NAMESPACE: データベース クラスタの Namespace。
バックアップ プランを削除せずに一時停止するには、バックアップ プランのリソースの paused 属性を true に設定します。バックアップ プランを一時停止しても、バックアップは引き続き保存されます。また、手動バックアップの作成は可能です。