障害復旧

障害復旧モード

Kubernetes Operator は、次のいずれかのモードを使用して、障害復旧シナリオで MongoDB MultiCluster リソースの自動または手動修復のいずれかを調整できます。

• 自動フェイルオーバー モードを使用すると、Kubernetes Operator は、影響を受ける MongoDB レプリカセット メンバーを、正常でない Kubernetes クラスターから正常な Kubernetes クラスターに移行できます。 Kubernetes Operator がこの自動修正を実行すると、レプリカセット メンバーが正常な Kubernetes クラスター全体に均等に分散されます。

  このモードを有効にするには、 Kubernetes用のMongoDB Helm Charts で --set multiCluster.performFailover=true を使用します。values.yamlKubernetesディレクトリ用のMongoDB Helm Charts ディレクトリ内の ファイルでは、環境の変数のデフォルト値はtrue です。

  あるいは、次の省略された例のように、マルチ Kubernetes クラスター MongoDB 配置環境変数PERFORM_FAILOVERをtrueに設定することもできます。

  spec:
    template:
      ...
      spec:
        containers:
        - name: mongodb-enterprise-operator
          ...
          env:
          ...
          - name: PERFORM_FAILOVER
            value: "true"
          ...

• 手動（プラグインベース）フェイルオーバー モードでは、 MongoDB kubernetesプラグインを使用して、新しい正常なKubernetesクラスターを使用するようにKubernetes Operator を再構成 できます 。このモードでは 、 構成に基づいて MongoDB MultiClusterリソースを構成し、新しい正常なクラスター全体にレプリカセットノードを分散します。

  このモードを有効にするには、Kubernetes用のMongoDB Helm Charts で --set multiCluster.performFailover=true を使用するか、次の省略された例のように、マルチ Kubernetes クラスターのMongoDBデプロイ環境変数 PERFORM_FAILOVER を false に設定します。

  spec:
    template:
      ...
      spec:
        containers:
        - name: mongodb-enterprise-operator
          ...
          env:
          ...
          - name: PERFORM_FAILOVER
            value: "false"
          ...

MongoDB プラグインを使用した障害からの手動回復

1 つ以上の Kubernetes Operator インスタンスをホストしている Kubernetes クラスターがダウンした場合、またはレプリカセット ノードが、それを管理する Kubernetes と同じ失敗した Kubernetes クラスターに存在する場合、自動または手動フェイルオーバー モードに依存することはできず、次のコマンドを使用する必要があります障害が発生した Kubernetes クラスターから手動で回復する手順。

次の手順では、 MongoDB kubernetes プラグインを使用して次のようにします。

• 新しい正常な Kubernetes クラスターを構成します。

• これらの Kubernetes クラスターを新しいノード クラスターとして、マルチ Kubernetes クラスター MongoDB 配置のmongodb-enterprise-operator-member-list ConfigMap に追加します。

• 正常なKubernetesクラスター内のノードで MongoDB MultiCluster リソースをホストしているノードを再調整します。

手動障害復旧に関する次のチュートリアルでは、次のことを前提としています。

• マルチKubernetes-クラスター クイック スタート に従って、1 つの演算子クラスターと 3 つのノードクラスターを配置しました。この場合、 Kubernetes Operator は、--set multiCluster.performFailover=false で無効になっている自動フェイルオーバーを使用してインストールされます。

• MongoDB MultiClusterリソースを次のように配置します。

  kubectl apply -n mongodb -f - <<EOF
  apiVersion: mongodb.com/v1
  kind: MongoDBMultiCluster
  metadata:
   name: multi-replica-set
  spec:
   version: 6.0.5-ent
   type: ReplicaSet
   persistent: false
   duplicateServiceObjects: true
   credentials: my-credentials
   opsManager:
     configMapRef:
       name: my-project
   security:
     tls:
       ca: custom-ca
   clusterSpecList:
     - clusterName: ${MDB_CLUSTER_1_FULL_NAME}
       members: 3
     - clusterName: ${MDB_CLUSTER_2_FULL_NAME}
       members: 2
     - clusterName: ${MDB_CLUSTER_3_FULL_NAME}
       members: 3
  EOF

Kubernetes Operator は、対応するサーバーの /readyz エンドポイントを ping して、マルチ Kubernetes クラスターMongoDBデプロイ内のクラスターへの接続を定期的にチェックします。/readyz の詳細については、Kubernetes APIヘルス エンドポイント を参照してください。

この例の CLUSTER_3 が使用できなくなった場合、 Kubernetes Operator はクラスターへの接続の失敗を検出し、次回の調整のために MongoDB MultiCluster リソースを failedClusters アノテーションでマークします。

このクラスターに配置されたデータ ノードを含むリソースは、次の手順のように手動で回復手順を実行するまで、調整に失敗します。

MongoDB データ ノードを再バランスして、すべてのワークロードがCLUSTER_1とCLUSTER_2で実行されるようにするには、次の手順に従います。

kubectl mongodb multicluster recover \
  --central-cluster="MDB_CENTRAL_CLUSTER_FULL_NAME" \
  --member-clusters="${MDB_CLUSTER_1_FULL_NAME},${MDB_CLUSTER_2_FULL_NAME}" \
  --member-cluster-namespace="mongodb" \
  --central-cluster-namespace="mongodb" \
  --operator-name=mongodb-enterprise-operator-multi-cluster \
  --source-cluster="${MDB_CLUSTER_1_FULL_NAME}"

kubectl apply -n mongodb -f - <<EOF
apiVersion: mongodb.com/v1
kind: MongoDBMultiCluster
metadata:
  name: multi-replica-set
spec:
  version: 6.0.0-ent
  type: ReplicaSet
  persistent: false
  duplicateServiceObjects: true
  credentials: my-credentials
  opsManager:
    configMapRef:
      name: my-project
 security:
   tls:
     ca: custom-ca
 clusterSpecList:
   - clusterName: ${MDB_CLUSTER_1_FULL_NAME}
     members: 4
   - clusterName: ${MDB_CLUSTER_2_FULL_NAME}
     members: 3
 EOF

GitOps Workflows を使用した障害からの手動回復

Argo CD を使用した GitOps ワークフローでのMongoDB kubertl プラグインの使用例については、 GitOps 用のマルチクラスター プラグインの例を参照してください。

GitOps の復元には、 リソースファイルを使用した ロールベースのアクセス制御 .yamlの手動再構成が必要です。詳しくは、「 Kubernetes のロールとロール バインディングの理解 」を参照してください。