Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 演算子
/

障害復旧

項目一覧

  • 障害復旧モード
  • MongoDB プラグインを使用した障害からの手動回復
  • MongoDB kubernetes プラグインを使用して、複数の Kubernetes クラスターの MongoDB 配置を回復します。
  • 正常な Kubernetes クラスター上のデータ ノードを再バランスをとります。
  • GitOps Workflows を使用した障害からの手動回復

Kubernetes Operator は、Kubernetes Operator が元の Kubernetes クラスターがダウンしていることを識別する場合に、MongoDB レプリカセット メンバーを正常な Kubernetes クラスターに回復するように調整できます。

Kubernetes Operator は、次のいずれかのモードを使用して、障害復旧シナリオで MongoDBMultiClusterリソースの自動または手動修復のいずれかをオーケストレーションできます。

  • 自動フェイルオーバー モードを使用すると、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_FAILOVERtrueに設定することもできます。

    spec:
    template:
    ...
    spec:
    containers:
    - name: mongodb-enterprise-operator
    ...
    env:
    ...
    - name: PERFORM_FAILOVER
    value: "true"
    ...
  • 手動(プラグインベース)フェイルオーバー モードでは、 MongoDB kubernetes プラグインを使用して、新しい正常な Kubernetes クラスターを使用するように Kubernetes Operator を再構成 します。 このモードでは、構成に基づいてMongoDBMultiClusterリソースを構成し、新しい正常なクラスター全体にレプリカセット ノードを分散します。

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

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

注意

1 つ以上の Kubernetes Operator インスタンスをホストしている Kubernetes クラスターがダウンした場合、またはレプリカセット ノードが、それを管理する Kubernetes と同じ失敗した Kubernetes クラスター上に存在する場合、自動または手動フェイルオーバー モードに依存することはできません。

このような場合、失われた Kubernetes クラスターから残りの正常な Kubernetes クラスターにレプリカセット ノードを復元するには、まず複数の Kubernetes クラスター MongoDB 配置を管理する Kubernetes Operator インスタンスを復元するか、Kubernetes Operator を残りの Kubernetes クラスターの 1 つに再デプロイする必要があります。をクリックし、 kubectl mongodbプラグインを再実行します。 詳細については、「 MongoDB プラグインを使用した障害からの手動回復 」を参照してください。

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

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

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

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

  • 正常な Kubernetes クラスター内のノードでMongoDBMultiClusterリソースをホストしているノードを再バランス化します。

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

  • マルチ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: 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 は、対応するサーバーの/healthzエンドポイントを ping して、マルチ Kubernetes クラスター MongoDB 配置内のクラスターへの接続を定期的にチェックします。 /healthzの詳細については、「 Kubernetes API ヘルスエンドポイント 」を参照してください。 。

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

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

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

1
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}"

このコマンド:

  • 2 つの正常な Kubernetes クラスターのワークロードを管理するように Kubernetes Operator を再構成します。 (このリストには新しい Kubernetes クラスターも含まれる場合があります)。

  • 新しい Kubernetes クラスターのノード ノード構成の構成ソースとしてCLUSTER_1をマークします。 CLUSTER_1の構成と一致するようにロールとサービス アカウントの構成を複製します。

2

MongoDBMultiClusterリソースを再構成し、変更の影響を受けるリソースを編集して、正常な Kubernetes クラスター上のデータ ノードを再バランスします。

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

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

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

戻る

シャーディングされたクラスター