kubectl コマンドライン ツールの使用に関する基本的な知識が必要です。
概要
データベース クラスタで HA を有効にするには、プライマリ データベース インスタンスのスタンバイ レプリカを作成するように AlloyDB Omni Kubernetes Operator に指示します。AlloyDB Omni Operator は、このレプリカのデータを継続的に更新するようにデータベース クラスタを構成し、プライマリ インスタンスのデータのすべての変更と照合します。
HA の有効化
データベース クラスタで HA を有効にする前に、Kubernetes クラスタに次のものがあることを確認します。
- データの完全なコピーを 2 つ保存するストレージ
- 2 つのデータベース インスタンスを並列で実行するためのコンピューティング リソース
HA を有効にする手順は次のとおりです。
データベース クラスタのマニフェストを変更して、
specセクションの下にavailabilityセクションを追加します。このセクションでは、numberOfStandbysパラメータを設定して、追加するスタンバイの数を定義します。spec: availability: numberOfStandbys: NUMBER_OF_STANDBYSNUMBER_OF_STANDBYSは追加するスタンバイの数に置き換えます。最大値は5です。HA を設定して、必要なスタンバイの数がわからない場合は、まず値を1または2に設定します。マニフェストを再度適用します。
HA を無効にする
HA を無効にする手順は次のとおりです。
クラスタのマニフェストで
numberOfStandbysを0に設定します。spec: availability: numberOfStandbys: 0マニフェストを再度適用します。
データベース クラスタの HA を確認する
データベース クラスタの現在の HA ステータスを確認するには、そのクラスタのステータスの HAReady 状態を確認します。この値の status が True に設定されている場合、HA が設定され、データベース クラスタで動作しています。
この値をコマンドラインで確認するには、次のコマンドを実行します。
kubectl get dbcluster.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o jsonpath={.status.conditions[?(@.type == \'HAReady\')]} -n NAMESPACE次のように置き換えます。
DB_CLUSTER_NAME: データベース クラスタの名前。NAMESPACE: データベース クラスタの Namespace。
スタンバイ インスタンスにフェイルオーバーする
プライマリ インスタンスが 90 秒以上使用できなくなった場合、AlloyDB Omni Operator はプライマリ データベース インスタンスからスタンバイ インスタンスに自動的にフェイルオーバーします。
フェイルオーバーは、予期しない障害から迅速に復旧してダウンタイムを最小限に抑える場合に有効な方法です。ただし、バックアップが完全に更新される前にプライマリ データベースが使用できなくなった場合には、少量のデータが失われる可能性があります。
AlloyDB Omni Operator は、自動フェイルオーバーと手動フェイルオーバーの両方をサポートしています。自動フェイルオーバーはデフォルトで有効になっています。
フェイルオーバー後に、次の一連のイベントが発生します。
AlloyDB Omni Operator がプライマリ データベース インスタンスをオフラインにします。
AlloyDB Omni Operator がスタンバイ レプリカを新しいプライマリ データベース インスタンスにプロモートします。
AlloyDB Omni Operator が以前のプライマリ データベース インスタンスを削除します。
AlloyDB Omni Operator が新しいスタンバイ レプリカを作成します。
自動フェイルオーバーを無効にする
自動フェイルオーバーは、データベース クラスタでデフォルトで有効になっています。
フェイルオーバーを無効にする手順は次のとおりです。
クラスタのマニフェストで
enableAutoFailoverをfalseに設定します。spec: availability: enableAutoFailover: falseマニフェストを再度適用します。
手動フェイルオーバーをトリガーする
手動フェイルオーバーをトリガーするには、新しいフェイルオーバー リソースのマニフェストを作成して適用します。
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Failover
metadata:
name: FAILOVER_NAME
namespace: NAMESPACE
spec:
dbclusterRef: DB_CLUSTER_NAME
次のように置き換えます。
FAILOVER_NAME: このリソースの名前(例:failover-1)。NAMESPACE: このフェイルオーバー リソースの Namespace。適用先のデータベース クラスタの Namespace と一致する必要があります。DB_CLUSTER_NAME: フェイルオーバーするデータベース クラスタの名前。
フェイルオーバーをモニタリングするには、次のコマンドを実行します。
kubectl get failover FAILOVER_NAME -o jsonpath={.status.state} -n NAMESPACE次のように置き換えます。
FAILOVER_NAME: 作成時にフェイルオーバー リソースに割り当てた名前。NAMESPACE: データベース クラスタの Namespace。
新しいプライマリ データベース インスタンスの使用準備が整うと、コマンドが Success を返します。新しいスタンバイ インスタンスのステータスをモニタリングするには、次のセクションをご覧ください。
スタンバイ インスタンスへのスイッチオーバー
スイッチオーバーは、プライマリ データベースとスタンバイ レプリカのロールの切り替えが必要な障害復旧の設定やその他の計画済みアクティビティをテストする場合に行われます。
スイッチオーバーが完了すると、レプリケーションの方向とともに、プライマリ データベース インスタンスとスタンバイ レプリカのロールが逆になります。データ損失なしで障害復旧設定のテストをより細かく制御する場合は、スイッチオーバーを選択する必要があります。
AlloyDB Omni Operator は手動スイッチオーバーをサポートしています。
スイッチオーバーでは、次の一連のイベントが発生します。
AlloyDB Omni Operator がプライマリ データベース インスタンスをオフラインにします。
AlloyDB Omni Operator がスタンバイ レプリカを新しいプライマリ データベース インスタンスにプロモートします。
AlloyDB Omni Operator が以前のプライマリ データベース インスタンスをスタンバイ レプリカに切り替えます。
切り替えを行う
スイッチオーバーを実行する前に、次のことを確認します。
- プライマリ データベース インスタンスとスタンバイ レプリカの両方が正常な状態であることを確認します。詳細については、AlloyDB Omni を管理してモニタリングするをご覧ください。
- 現在の HA ステータスが
HAReady状態であることを確認します。詳細については、データベース クラスタの HA を確認するをご覧ください。
スイッチオーバーを実行するには、新しい切り替えリソースのマニフェストを作成して適用します。
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Switchover
metadata:
name: SWITCHOVER_NAME
spec:
dbclusterRef: DB_CLUSTER_NAME
NewPrimary: STANDBY_REPLICA_NAME
次のように置き換えます。
SWITCHOVER_NAME: この切り替えリソースの名前。例:switchover-1DB_CLUSTER_NAME: スイッチオーバー オペレーションが適用されるプライマリ データベース インスタンスの名前。STANDBY_REPLICA_NAME: 新しいプライマリとして昇格するデータベース インスタンスの名前。スタンバイ レプリカ名を特定するには、コマンド
posix-terminal kubectl get instances.alloydbomni.internal.dbadmin.googを実行します。
スタンバイ レプリカを読み取り専用インスタンスとして使用する
スタンバイ レプリカを読み取り専用インスタンスとして使用する手順は次のとおりです。
データベース クラスタのマニフェストを変更して、
enableStandbyAsReadReplicaパラメータをtrueに設定します。spec: availability: enableStandbyAsReadReplica: trueマニフェストを再度適用します。
読み取り専用エンドポイントが
DBClusterオブジェクトのstatusフィールドで報告されていることを確認します。kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME次のレスポンス例は、読み取り専用インスタンスのエンドポイントを示しています。
Status: [...] Primary: [...] Endpoints: Name: Read-Write Value: 10.128.0.81:5432 Name: Read-Only Value: 10.128.0.82:5432