Ops Managerアプリケーションインスタンスまたはアプリケーションデータベースノードを実行しているKubernetesクラスターが失敗しても、中央クラスターが利用可能な場合は、Kubernetes演算子を使用して、次のシナリオに基づいてアプリケーションデータベースのレプリカセットと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 クラスター上のレプリカセットのノードをスケールダウンして、レプリカセットを再構成し、これらのノードを含めないようにすることもできます。If a majority of replica set's nodes fail, the replica set can't form a voting majority to elect a primary node. To learn more, see Replica Set Deployment Architectures. In this case, if at least one node in an Application Database's replica set remains available, then no data is lost. Because there is no primary node in a replica set, you must forcibly reconfigure the replica set to add new replica set nodes. The nodes will form a voting majority allowing the replica set to elect a primary. New Application Database instances will sync with the healthy nodes to receive the data.
If all Kubernetes member clusters hosting the Application Database's replica set nodes fail, this causes an irreversible data loss (Ops Manager doesn't back up the Application Database). If possible, use an odd number of member Kubernetes clusters and distribute your Application Database nodes across data centers, zones, or Kubernetes clusters. To learn more, see Replica Sets Distributed Across Two or More Data Centers.