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

演算子クラスターが障害した場合のMongoDB Ops Managerの回復

項目一覧

  • Kubernetes Operator とMongoDB Ops Managerの回復

Operator と KubernetesアプリケーションをホストしているKubernetesMongoDB Ops Manager クラスターに障害が発生した場合は、 演算子クラスターとMongoDB Ops Manager アプリケーションを手動で回復できます。

MongoDB Ops Managerの以前の実行状態を復元するには、 MongoDB Ops Managerとアプリケーション データベース リソースに対して定期的なバックアップ メカニズムを構成します。 Kubernetes Operator は、 MongoDB Ops Managerアプリケーションの配置を管理するためにこれらのリソースを必要とします。

KubernetesOperator とMongoDB Ops Manager MongoDB Ops Managerを復元するには、新しいKubernetes クラスターで リソースを復元します。

1

手順に従って、新しい Kubernetes クラスターにKubernetes Operatorインストールします。

注意

ノードクラスターを再利用する場合は、適切なサービス アカウントとロールが存在することを確認してください。 これらの値は重複する可能性があり、中央クラスターとノードクラスター間で権限が異なる場合があります。

Kubernetes Operator に必要な適切なロールを確認するには、 公開リポジトリの サンプルを参照してください。

2

オブジェクト のコピー 失敗した リソースの仕様を変更し、次のリソースを検索し、プレースホルダー テキストを特定のMongoDB Ops ManagerMongoDB Ops Manager リソース名と名前空間に置き換えます。

リソース タイプ
Values
シークレット
  • <om-name>-db-om-password

  • <om-name>-db-agent-password

  • <om-name>-db-keyfile

  • <om-name>-db-om-user-scram-credentials

  • <om-namespace>-<om-name>-admin-key

  • <om-name>-admin-secret

  • <om-name>-gen-key

  • TLS証明書の秘密(任意)

ConfigMaps
  • <om-name>-db-cluster-mapping

  • <om-name>-db-member-spec

  • TLS証明書のカスタム CA(任意)

OpsManager
  • <om-name>

次に、コピーした仕様を新しい ファイルに貼り付け、前述の値を使用して新しいリソースを構成します。 詳細については、「 MongoDB Ops Managerリソースの配置 」を参照してください。

3

次のコマンドを使用して、更新されたリソースを適用します。

kubectl apply \
--context "$MDB_CENTRAL_CLUSTER_FULL_NAME" \
--namespace "mongodb"
-f https://raw.githubusercontent.com/mongodb/mongodb-enterprise-kubernetes/master/samples/ops-manager/ops-manager-external.yaml

MongoDB Ops Manager リソースのステータスを確認するには、次のコマンドを使用します。

kubectl get om -o yaml -w

中央クラスターがRunning状態に達したら、アプリケーション データベースを必要なメンバー クラスターの分散にリスケールできます。

この時点で、新しく復元された Kubernetes Operator は、既存のアプリケーション データベースの管理を選択します。

注意

アプリケーション データベースのレプリカセットでいくつかのノードがなくなり、投票過半数を形成できない場合は、 レプリカセット を強制的に再構成します。 これにより、投票権の過半数を形成する新しいレプリカセット ノードが追加され、レプリカセットがプライマリを選出できるようになります。

戻る

使用可能なクラスターの回復