如果托管Kubernetes KubernetesOperatorMongoDB Ops Manager 和 应用程序的 集群出现故障，您可以手动恢复 Operator 集群和MongoDB Ops Manager 应用程序。
要恢复MongoDB Ops Manager之前的运行状态，请为MongoDB Ops Manager和应用程序数据库资源配置定期备份机制。 Kubernetes Operator 需要这些资源来管理MongoDB Ops Manager应用程序部署。
恢复Kubernetes Operator 和MongoDB Ops Manager
要恢复 Kubernetes 操作符 和 Ops Manager，请在新的 Kubernetes 集群上恢复 Ops Manager 资源：
在新集群中配置 Kubernetes Operator。
按照说明在新的 Kubernetes 集群中安装 Kubernetes 操作符 。
注意
如果计划重复使用成员集群，请确保存在适当的服务帐户和角色。 这些值可以重叠，并且在中央集群和成员集群之间具有不同的权限。
要查看Kubernetes Operator 所需的相应角色，请参阅公共存储库中的示例。
从出现故障的 Ops Manager 资源中检索已备份的资源。
复制失败的Ops Manager资源的对象规范并检索以下资源，用特定Ops Manager资源名称和命名空间替换占位符文本。
资源类型 | Values |
|---|---|
秘密 |
|
ConfigMap |
|
Ops Manager |
|
然后，将复制的规范粘贴到新文件中，并使用前面的值配置新资源。 要了解更多信息，请参阅部署 Ops Manager 资源。
将 Ops Manager 资源重新应用于新集群。
使用以下命令应用更新的资源：
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
要检查您的 Ops Manager 资源的状态，请使用以下命令：
kubectl get om -o yaml -w
一旦中央集群达到Running状态，您就可以将应用程序数据库重新扩展到所需的成员集群分布。
点，新恢复的Kubernetes Operator 应接管对现有应用程序数据库的管理。
用于创建初始项目的ConfigMap 。
上一个Kubernetes Operator 实例中使用的密钥。
源集群上上次可用状态的 或
MongoDBMongoDBMulticluster自定义资源，包括Kubernetes Operator 在其生命周期中添加的任何注释。
注意
If the Application Database replica set has lost some nodes and is unable to form a voting majority, forcibly reconfigure the replica set. This adds new replica set nodes that will form a voting majority allowing the replica set to elect a primary.