AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。

障害復旧

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

障害復旧モード

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

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_FAILOVERをtrueに設定することもできます。

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

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

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

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

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

注意

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

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

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

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

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

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

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

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

    MongoDBMultiCluster リソース

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

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

  • 中央クラスター1つとノードクラスター3つを配置しました。Multi-Kubernetes-Cluster Quick Startに従います。この場合、Kubernetes 演算子は自動フェイルオーバーを無効にして--set multiCluster.performFailover=falseでインストールされます。

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

    kubectl apply -n mongodb -f - <<EOFapiVersion: mongodb.com/v1kind: MongoDBMultiClustermetadata: name: multi-replica-setspec: 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: 3EOF

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

この例のCLUSTER_3が使用できなくなった場合、Kubernetes 演算子はクラスターへの接続の失敗を検出し、

MongoDBMultiCluster リソース

後続の調整のための failedClusters アノテーション。クラスターがヘルスチェックを設定された回数連続して合格すると、演算子はこのアノテーションを削除します。

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

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

1

MongoDB kubernetes クラスターのMongoDB配置を回復するには、MongoDB kubectlプラグインを使用します。

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

このコマンド:

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

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

2

正常な Kubernetes クラスター上のデータ ノードを再バランスをとります。

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

kubectl apply -n mongodb -f - <<EOFapiVersion: mongodb.com/v1kind: MongoDBMultiClustermetadata:  name: multi-replica-setspec:  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 を使用した障害からの手動回復

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

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

戻る
サービス メトリクスを持たないシャードクラスタ
次へ
シャードクラスタの障害復旧
このページを評価

項目一覧