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 オペレーターはプライマリ データベース インスタンスからスタンバイ インスタンスに自動的にフェイルオーバーします。自動フェイルオーバーを開始するタイミングは、次のパラメータによって決まります。

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

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

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

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

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

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

1. AlloyDB Omni オペレーターは、プライマリ データベース インスタンスをオフラインにします。

2. AlloyDB Omni オペレーターは、スタンバイ レプリカを新しいプライマリ データベース インスタンスに昇格させます。

3. AlloyDB Omni オペレーターは、以前のプライマリ データベース インスタンスを削除します。

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

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

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

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

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

   spec:
     availability:
       enableAutoFailover: false
   

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

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

AlloyDB Omni オペレーターは、プライマリ データベース インスタンスとすべてのスタンバイ レプリカに対して定期的なヘルスチェックを実行します。ヘルスチェックのデフォルトの頻度は 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: このフェイルオーバー リソースの名前空間。適用先のデータベース クラスタの名前空間と一致する必要があります。

• DB_CLUSTER_NAME: フェイルオーバーするデータベース クラスタの名前。

フェイルオーバーをモニタリングするには、次のコマンドを実行します。

kubectl get failover FAILOVER_NAME -o jsonpath={.status.state} -n NAMESPACE

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

• FAILOVER_NAME: 作成時にフェイルオーバー リソースに割り当てた名前。

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

新しいプライマリ データベース インスタンスの使用準備が整うと、コマンドは Success を返します。新しいスタンバイ インスタンスのステータスをモニタリングするには、次のセクションをご覧ください。

スタンバイ インスタンスへのスイッチオーバー

スイッチオーバーは、障害復旧の設定をテストする場合や、プライマリ データベースとスタンバイ レプリカのロール切り替えが必要なその他の計画されたアクティビティを行う場合に実行されます。

スイッチオーバーが完了すると、レプリケーションの方向とプライマリ データベース インスタンスとスタンバイ レプリカのロールが逆になります。切り替えを使用して、データ損失なしで障害復旧設定のテストにより細かく制御できます。

AlloyDB Omni オペレーターは手動スイッチオーバーをサポートしています。スイッチオーバーでは、次のイベントの順序が発生します。

1. AlloyDB Omni オペレーターは、プライマリ データベース インスタンスをオフラインにします。

2. AlloyDB Omni オペレーターは、スタンバイ レプリカを新しいプライマリ データベース インスタンスに昇格させます。

3. AlloyDB Omni オペレーターは、以前のプライマリ データベース インスタンスをスタンバイ レプリカに切り替えます。

注: スタンバイ レプリカを読み取り専用インスタンスとして使用するように構成できます。詳細については、スタンバイを読み取り専用インスタンスとして使用するをご覧ください。

切り替えを行う

切り替えを開始する前に、次の操作を行います。

• プライマリ データベース インスタンスとスタンバイ レプリカの両方が正常な状態であることを確認します。詳細については、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

重要: スイッチオーバーの実行前にローカル バックアップが作成されている場合、Restore カスタム リソースを使用して復元することはできません。バックアップを手動でクローンを作成する場合は、ローカル バックアップを使用して Kubernetes でデータベース クラスタをクローンを作成するをご覧ください。

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

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

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

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

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

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

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

   spec:
     availability:
       enableAutoHeal: false
   

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

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

AlloyDB Omni オペレーターは、構成可能な定期的なヘルスチェックを実行します。詳細については、自動フェイルオーバー トリガーの設定を調整するをご覧ください。スタンバイ レプリカが自動修復トリガーのしきい値に達すると、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 オペレータの CPU 上限、メモリ上限、またはその両方を増やします。詳細については、自動メモリ管理についてと AlloyDB Omni オペレーターのメモリヒープ使用量を分析するをご覧ください。

自動修復の処理が過負荷になった場合に発生する可能性のあるエラーの例を次に示します。これらの例では、エラーの原因を特定するのに役立つ環境の詳細（クラスタの名前や 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