演算子クラスターが稼働中の場合にMongoDB Ops Managerと AppDB を回復する

KubernetesMongoDB Ops Managerアプリケーション インスタンスまたはアプリケーション データベース ノードを実行している クラスターに障害が発生しても、演算子クラスターが使用可能な場合は、Kubernetes Operator を使用して、次のシナリオに基づいてアプリケーション データベースのレプリカセットと アプリケーション インスタンスの配置を再構成できます。MongoDB Ops Manager :

• MongoDB Ops Managerアプリケーションの一部またはすべてのインスタンスが失敗しても、 MongoDB Ops Managerアプリケーションはステートレスであるため、データは失われません。 MongoDB Ops ManagerApplicationMongoDB Ops Manager の可用性を高めるには、すでに構成されて使用可能なKubernetes ノードクラスターに新しい ApplicationKubernetes インスタンスを追加するか、MongoDB Ops Manager Application インスタンスを実行するための新しい クラスターを追加します。

• 調整プロセス中にレプリカセットのノードの少数のみに障害が発生し、レプリカセット内の大多数のノードが使用可能な場合、Kubernetes Operator は失敗した Kubernetes クラスターを無視し、アプリケーション データベースは書込み可能な状態のままになります。

  spec.applicationDatabase.clusterSpecList設定を使用して、アプリケーション データベースのレプリカセット ノードをすでに構成され使用可能なメンバーの Kubernetes クラスターに追加するか、アプリケーション データベースの失敗したレプリカセット メンバーを配置する新しい Kubernetes クラスターを追加します。 また、失敗した Kubernetes クラスター上のレプリカセットのノードをスケールダウンして、レプリカセットを再構成し、これらのノードを含めないようにすることもできます。

• レプリカセットのノードの過半数が失敗した場合、レプリカセットはプライマリ ノードを選出するための投票過半数を形成できません。 詳しくは、 レプリカセット配置のアーキテクチャを参照してください。 この場合、アプリケーション データベースのレプリカセット内の少なくとも 1 つのノードが使用可能な状態であれば、データは失われません。 レプリカセットにはプライマリ ノードがないため、新しいレプリカセット ノードを追加するには、レプリカセットを強制的に再構成する必要があります。 ノードは投票権の過半数を形成し、レプリカセットがプライマリを選出できるようにします。 新しいアプリケーション データベース インスタンスは、正常なノードと同期してデータを受け取ります。

• アプリケーション データベースのレプリカセット ノードをホストしているすべてのKubernetesノード クラスターに障害が発生すると、不可分的なデータが失われます（ MongoDB Ops Managerはアプリケーション データベースをバックアップしません）。 可能であれば、奇数のメンバー Kubernetes クラスターを使用し、 アプリケーションデータベース ノードをデータセンター、ゾーン、または Kubernetes クラスターに分散します。 詳しくは、「 2 つ以上のデータセンターに分散されたレプリカセット 」を参照してください。