障害復旧

障害復旧モード

Kubernetes 演算子は、次の自動または手動での修正を調整できます:

MongoDBMultiCluster リソース

次のいずれかのモードを使用して、障害復旧シナリオでリソースを確保します。

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

  To enable this mode, use --set multiCluster.performFailover=true in the MongoDB Helm Charts for Kubernetes. In the values.yaml file in the MongoDB Helm Charts for Kubernetes directory, the environment's variable default value is true.

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

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

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

  To enable this mode, use --set multiCluster.performFailover=true in the MongoDB Helm Charts for Kubernetes, or set the multi-Kubernetes cluster MongoDB deployment environment variable PERFORM_FAILOVER to false, as in the following abbreviated example:

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

自動フェイルオーバーが無効になっている場合、クラスターがヘルスチェックを設定された回数連続して合格すると、演算子は failedClusters アノテーションを削除します。このスレッショルドは、環境変数またはHelm値を使用して構成できます。

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

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

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

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

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

• ホスティングノードのリバランス

  MongoDBMultiCluster リソース

  正常な Kubernetes クラスターのノード上で。

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

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

• MongoDBMultiClusterリソースを次のように配置しました。

  kubectl apply -n mongodb -f - <<EOF
  apiVersion: mongodb.com/v1
  kind: MongoDBMultiCluster
  metadata:
   name: multi-replica-set
  spec:
   version: 8.0.0
   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 演算子はクラスターへの接続の失敗を検出し、

MongoDBMultiCluster リソース

後続の調整のための 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-kubernetes-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: 8.0.0
  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 を使用した障害からの手動回復

For an example of use of the MongoDB kubectl plugin in a GitOps workflow with Argo CD, see multi-cluster plugin example for GitOps.

GitOps recovery requires manual reconfiguration of Role Based Access Control using .yaml resource files. To learn more, see Understand Kubernetes Roles and Role Bindings.