在 Operator 集群出现故障时恢复MongoDB Ops Manager
如果托管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 Operator 。
注意
如果计划重复使用成员集群，请确保存在适当的服务帐户和角色。 这些值可以重叠，并且在中央集群和成员集群之间具有不同的权限。
要查看Kubernetes Operator 所需的相应角色，请参阅公共存储库中的 存储库。
从出现故障的 Ops Manager 资源中检索已备份的资源。
复制MongoDB Ops Manager 对象 失败的 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-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 在其生命周期中添加。
注意
如果应用程序数据库副本集丢失了一些节点，无法形成投票多数，请强制重新配置副本集。 这会添加新的副本集节点，这些节点将形成投票多数，允许副本集选举主节点 (primary node in the replica set)节点。