Kubernetes で高可用性を管理する

このドキュメントでは、Kubernetes ベースの AlloyDB Omni データベース クラスタで高可用性（HA）を有効にしてテストする方法について説明します。このドキュメントは、Kubernetes マニフェスト ファイルの適用と kubectl コマンドライン ツールの使用に関する基本的な知識があることを前提に作成されています。

概要

データベース クラスタで HA を有効にするには、プライマリ データベース インスタンスのスタンバイ レプリカを作成するように AlloyDB Omni Kubernetes オペレーターを構成します。AlloyDB Omni オペレーターは、このレプリカのデータを継続的に更新するようにデータベース クラスタを構成し、プライマリ インスタンスのすべてのデータ変更と照合します。

HA を有効にする

データベース クラスタで HA を有効にする前に、Kubernetes クラスタに次のものがあることを確認します。

• データの完全なコピーを 2 つ保存するストレージ

• 2 つのデータベース インスタンスを並列で実行するためのコンピューティング リソース

HA を有効にする手順は次のとおりです。

1. データベース クラスタのマニフェストを変更して、spec セクションの下に availability セクションを追加します。このセクションでは、numberOfStandbys パラメータを使用して、追加するスタンバイの数を指定します。

   spec:
     availability:
       numberOfStandbys: NUMBER_OF_STANDBYS
   

   NUMBER_OF_STANDBYS は、追加するスタンバイの数に置き換えます。最大値は 5 です。必要なスタンバイの数がわからない場合は、まず値を 1 または 2 に設定します。

2. マニフェストを再度適用します。

HA を無効にする

HA を無効にする手順は次のとおりです。

1. クラスタのマニフェストで numberOfStandbys を 0 に設定します。

   spec:
     availability:
       numberOfStandbys: 0
   

2. マニフェストを再度適用します。

データベース クラスタの HA を確認する

データベース クラスタの HA のステータスを確認するには、HAReady ステータスを確認します。HAReady のステータスが True の場合は、クラスタで HA が有効かつ動作しています。False の場合は、有効になっていますが、設定中であるため、まだ準備ができていません。

kubectl コマンドラインを使用して HAReady のステータスを確認するには、次のコマンドを実行します。

kubectl get dbcluster.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o jsonpath={.status.conditions[?(@.type == \'HAReady\')]} -n NAMESPACE

次のように置き換えます。

• DB_CLUSTER_NAME: データベース クラスタの名前。

• NAMESPACE: データベース クラスタの Namespace。

スタンバイ インスタンスにフェイルオーバーする

プライマリ インスタンスが構成可能な一定期間にわたり使用できなくなった場合、AlloyDB Omni Operator はプライマリ データベース インスタンスからスタンバイ インスタンスに自動的にフェイルオーバーします。自動フェイルオーバーを開始するタイミングは、次のパラメータによって決まります。

• ヘルスチェックの間隔（デフォルトは 30 秒）

• ヘルスチェックの連続失敗回数（デフォルトは 3 回）

自動フェイルオーバーは、各ヘルスチェックの失敗間に指定された時間が経過した形で、指定された回数連続してヘルスチェックに失敗すると開始されます。デフォルト値をそのまま使用した場合、30 秒間隔で 3 回連続してヘルスチェックに失敗すると、自動フェイルオーバーが発生します。

手動フェイルオーバーは、予期しない障害から迅速に復旧し、ダウンタイムを最小限に抑える場合に適しています。

AlloyDB Omni Operator は、自動フェイルオーバーと手動フェイルオーバーの両方をサポートしています。自動フェイルオーバーはデフォルトで有効になっています。

フェイルオーバー後に、次の一連のイベントが発生します。

1. AlloyDB Omni Operator がプライマリ データベース インスタンスをオフラインにします。

2. AlloyDB Omni Operator がスタンバイ レプリカを新しいプライマリ データベース インスタンスにプロモートします。

3. AlloyDB Omni Operator が以前のプライマリ データベース インスタンスを削除します。

4. AlloyDB Omni Operator が新しいスタンバイ レプリカを作成します。

自動フェイルオーバーを無効にする

自動フェイルオーバーは、データベース クラスタでデフォルトで有効になっています。

フェイルオーバーを無効にする手順は次のとおりです。

1. クラスタのマニフェストで enableAutoFailover を false に設定します。

   spec:
     availability:
       enableAutoFailover: false
   

自動フェイルオーバー トリガーの設定を調整する

設定を使用して、各データベース クラスタの自動フェイルオーバーを調整できます。

AlloyDB Omni Operator は、プライマリ データベース インスタンスとすべてのスタンバイ レプリカに対して定期的なヘルスチェックを実行します。ヘルスチェックのデフォルトの頻度は 30 秒です。インスタンスが自動フェイルオーバー トリガーのしきい値に達すると、AlloyDB Omni オペレーターは自動フェイルオーバーをトリガーします。

しきい値は、フェイルオーバーがトリガーされるまでのへルスチェックの連続失敗回数です。ヘルスチェックの期間またはしきい値を変更するには、クラスタのマニフェストで healthcheckPeriodSeconds フィールドと autoFailoverTriggerThreshold フィールドを整数値に設定します。

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

次のように置き換えます。

• HEALTHCHECK_PERIOD: 次のヘルスチェックまでの待機時間（秒数）を示す整数値。デフォルト値は 30 です。最小値は 1、最大値は 86400（1 日に相当）です。

• AUTOFAILOVER_TRIGGER_THRESHOLD: フェイルオーバーがトリガーされるまでのヘルスチェックの連続失敗回数を示す整数値。デフォルト値は 3 です。最小値は 0 です。最大値はありません。このフィールドが 0 に設定されている場合、代わりにデフォルト値の 3 が使用されます。

手動フェイルオーバーをトリガーする

手動フェイルオーバーをトリガーするには、新しいフェイルオーバー リソースのマニフェストを作成して適用します。

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 は手動スイッチオーバーをサポートしています。スイッチオーバーでは、次の一連のイベントが発生します。

1. AlloyDB Omni Operator がプライマリ データベース インスタンスをオフラインにします。

2. AlloyDB Omni Operator がスタンバイ レプリカを新しいプライマリ データベース インスタンスにプロモートします。

3. 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: STANBDY_REPLICA_NAME

次のように置き換えます。

• SWITCHOVER_NAME: この切り替えリソースの名前。例: switchover-1

• DB_CLUSTER_NAME: スイッチオーバー オペレーションが適用されるプライマリ データベース インスタンスの名前。

• STANBDY_REPLICA_NAME: 新しいプライマリにプロモートするデータベース インスタンスの名前。

  スタンバイ レプリカ名を特定するには、次のコマンドを実行します。

  kubectl get instances.alloydbomni.internal.dbadmin.goog

スタンバイ インスタンスを自動的に修復する

スタンバイ インスタンスが使用できなくなった場合、AlloyDB Omni オペレーターは古いスタンバイ レプリカを削除し、その代わりとなる新しいスタンバイ レプリカを作成してインスタンスを修復します。自動修復をトリガーするデフォルトの時間は 90 秒です。

データベース クラスタを自動的に修復すると、プライマリ データベースの正常で継続的なレプリケーションを維持できます。

インスタンスの自動修復を無効にする

スタンバイ インスタンスの自動修復は、データベース クラスタでデフォルトで有効になっています。

自動修復を無効にする手順は次のとおりです。

1. クラスタのマニフェストで、enableAutoHeal を false に設定します。

   spec:
     availability:
       enableAutoHeal: false
   

自動修復トリガーの設定を調整する

データベース クラスタごとに、設定を使用して自動修復を調整できます。

AlloyDB Omni Operator は、構成可能な定期的なヘルスチェックを実行します。詳細については、自動フェイルオーバー トリガーの設定を調整するをご覧ください。スタンバイ レプリカが自動修復トリガーのしきい値に達すると、AlloyDB Omni オペレーターが自動修復をトリガーします。

しきい値は、修復がトリガーされるまでのへルスチェックの連続失敗回数です。しきい値を変更するには、クラスタのマニフェストで autoHealTriggerThreshold を設定します。

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

次のように置き換えます。

• AUTOHEAL_TRIGGER_THRESHOLD: 修復がトリガーされるまでのヘルスチェックの連続失敗回数を示す整数値。デフォルト値は 3 です。スタンバイ ヘルスチェックで一時的な 1 回限りのエラーが発生する可能性があるため、最小値は 2 です。

インスタンスの修復のトラブルシューティング

単一の Kubernetes クラスタで大量のデータベース クラスタを使用すると、自動修復が機能しない場合があります。HealthCheckProber: health check for instance failed で始まり、タイムアウトまたは接続エラーを参照するエラーが表示された場合は、次のことでエラーを軽減できます。

• Kubernetes クラスタで管理しているデータベース クラスタの数を減らします。

• ヘルスチェックの頻度が減るよう、healthcheckPeriodSeconds しきい値を引き上げます。詳細については、自動フェイルオーバー トリガーの設定を調整するをご覧ください。

• AlloyDB Omni Operator の CPU 上限、メモリ上限、またはその両方を引き上げます。詳細については、自動メモリ管理についてと AlloyDB Omni Operator のメモリヒープ使用量を分析するをご覧ください。

自動修復の処理が過剰になった場合に発生する可能性のあるエラーの例を次に示します。これらの例では、エラーの原因特定に役立つ環境の詳細（クラスタ名や IP アドレスなど）を省略しています。

• HealthCheckProber: health check for instance failed" err="DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context deadline exceeded...

• HealthCheckProber: health check for instance failed" err="rpc error: code = Code(10303) desc = DBSE0303: Healthcheck: Health check table query failed. dbdaemon/healthCheck: read healthcheck table: timeout...

• HealthCheckProber: health check for instance failed" err="rpc error: code = Code(12415) desc = DBSE2415: Postgres: failed to connect to database. dbdaemon/healthCheck: failed to connect...

スタンバイ レプリカを読み取り専用インスタンスとして使用する

スタンバイ レプリカを読み取り専用インスタンスとして使用する手順は次のとおりです。

1. データベース クラスタのマニフェストで enableStandbyAsReadReplica を true に設定します。

   spec:
     availability:
       enableStandbyAsReadReplica: true
   

2. マニフェストを再度適用します。

3. 読み取り専用エンドポイントが 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