如果托管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 资源中检索已备份的资源。
复制失败的MongoDB Ops Manager资源的对象规范并检索以下资源，将占位符文本替换为特定的MongoDB 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-kubernetes/master/public/samples/ops-manager/ops-manager-external.yaml
要检查您的 Ops Manager 资源的状态，请使用以下命令：
kubectl get om -o yaml -w
一旦操作符集群达到 Running 状态，您就可以将应用程序数据库重新扩展到所需的成员集群分布。
点，新恢复的Kubernetes Operator 应接管对现有应用程序数据库的管理。
用于创建初始项目的ConfigMap 。
上一个Kubernetes Operator 实例中使用的密钥。
The
MongoDBorMongoDBMulticlustercustom resource at its last available state on the source cluster, including any annotations added by the Kubernetes Operator during its lifecycle.
注意
如果应用程序数据库副本集丢失了一些节点，无法形成投票多数，请强制重新配置副本集。 这会添加新的副本集节点，这些节点将形成投票多数，允许副本集选举主节点 (primary node in the replica set)节点。