灾难恢复
在此页面上
当 Kubernetes 操作符识别出原始 Kubernetes 集群已关闭时,Kubernetes 操作符可以协调将 MongoDB 副本集成员恢复到健康的 Kubernetes 集群。
灾难恢复模式
Kubernetes 操作符可以在灾难恢复场景中使用以下模式之一协调 MongoDBMultiCluster
资源的自动或手动修复:
自动故障转移模式允许 Kubernetes Operator 将受影响的 MongoDB 副本集成员从不健康的 Kubernetes 集群转移到健康的 Kubernetes 集群。 当 Kubernetes 操作符执行此自动修复时,它会在健康的 Kubernetes 集群之间平均分配副本集成员。
要启用此模式,请使用适用于Kubernetes的MongoDB Helm Charts中的
--set multiCluster.performFailover=true
。values.yaml
在MongoDB Helm Charts for Kubernetes 目录下的 文件中,环境变量默认值为true
。或者,您可以将多 Kubernetes 集群 MongoDB 部署环境变量
PERFORM_FAILOVER
设置为true
,如以下简短示例所示:spec: template: ... spec: containers: - name: mongodb-enterprise-operator ... env: ... - name: PERFORM_FAILOVER value: "true" ... 手动(基于插件)故障转移模式允许您使用 MongoDB kubectl 插件重新配置Kubernetes Operator,以使用新的健康Kubernetes集群。 在此模式,您可以根据您的配置配置
MongoDBMultiCluster
资源,以便在新的运行状况良好的集群中分配副本集成员。要启用此模式,请使用
--set multiCluster.performFailover=true
MongoDB Helm Charts for Kubernetes 中的 ,或将多 Kubernetes 集群 MongoDB 部署环境变量PERFORM_FAILOVER
设置为false
,如以下缩写示例所示:spec: template: ... spec: containers: - name: mongodb-enterprise-operator ... env: ... - name: PERFORM_FAILOVER value: "false" ...
注意
当托管一个或多个 Kubernetes Operator 实例的 Kubernetes 集群出现故障,或者副本集成员与管理它的 Kubernetes 驻留在同一故障 Kubernetes 集群时,您不能依赖自动或手动故障转移模式。
在这种情况下,要将副本集成员从丢失的 Kubernetes 集群恢复到剩余的健康 Kubernetes 集群,您必须首先恢复管理多 Kubernetes 集群 MongoDB 部署的 Kubernetes Operator 实例,或者将 Kubernetes Operator 重新部署到剩余的 Kubernetes 集群之一,然后重新运行kubectl mongodb
插件。 要了解更多信息,请参阅使用 MongoDB 插件从故障中手动恢复。
使用 MongoDB 插件从故障中手动恢复
当托管一个或多个 Kubernetes Operator 实例的 Kubernetes 集群出现故障,或者副本集成员与管理它的 Kubernetes 驻留在同一故障 Kubernetes 集群上时,您不能依赖自动或手动故障转移模式,而必须使用以下从失败的 Kubernetes 集群中手动恢复的过程。
以下过程使用MongoDB kubectl 插件执行以下操作:
配置新的运行状况良好的 Kubernetes 集群。
将这些 Kubernetes 集群作为新成员集群添加到多 Kubernetes 集群 MongoDB 部署的
mongodb-enterprise-operator-member-list
ConfigMap 中。重新平衡运行状况良好的 Kubernetes 集群中的节点上托管
MongoDBMultiCluster
资源的节点。
以下手动灾难恢复教程假设您:
按照Kubernetes 多集群快速入门部署了一个中央集群和三个成员集群。 在这种情况下,安装的 Kubernetes Operator 会使用
--set multiCluster.performFailover=false
禁用自动故障转移。已部署
MongoDBMultiCluster
资源,如下所示:kubectl apply -n mongodb -f - <<EOF apiVersion: mongodb.com/v1 kind: MongoDBMultiCluster metadata: name: multi-replica-set spec: version: 6.0.5-ent type: ReplicaSet persistent: false duplicateServiceObjects: true credentials: my-credentials opsManager: configMapRef: name: my-project security: tls: ca: custom-ca clusterSpecList: - clusterName: ${MDB_CLUSTER_1_FULL_NAME} members: 3 - clusterName: ${MDB_CLUSTER_2_FULL_NAME} members: 2 - clusterName: ${MDB_CLUSTER_3_FULL_NAME} members: 3 EOF
Kubernetes Operator 通过对相应服务器的/healthz
端点执行 ping 操作来定期检查与多 Kubernetes 集群 MongoDB 部署中集群的连接。 要了解有关/healthz
的更多信息,请参阅 Kubernetes API 运行状况端点 。
CLUSTER_3
如果示例中的 不可用,Kubernetes 操作符会检测到与集群的失败连接,并使用MongoDBMultiCluster
failedClusters
注解标记资源,以供后续协调。
在您按照以下过程运行手动恢复步骤之前,此集群上部署有数据节点的资源无法协调。
要重新平衡 MongoDB 数据节点,以便所有工作负载都在CLUSTER_1
和CLUSTER_2
上运行:
使用MongoDB kubectl 插件恢复多 Kubernetes集群MongoDB 部署。
kubectl mongodb multicluster recover \ --central-cluster="MDB_CENTRAL_CLUSTER_FULL_NAME" \ --member-clusters="${MDB_CLUSTER_1_FULL_NAME},${MDB_CLUSTER_2_FULL_NAME}" \ --member-cluster-namespace="mongodb" \ --central-cluster-namespace="mongodb" \ --operator-name=mongodb-enterprise-operator-multi-cluster \ --source-cluster="${MDB_CLUSTER_1_FULL_NAME}"
此命令:
重新配置 Kubernetes 操作符,以托管两个正常运行的 Kubernetes 集群上的工作负载。(此列表还可能包括新的 Kubernetes 集群)。
将
CLUSTER_1
标记为新 Kubernetes 集群的成员节点配置的配置源。 复制角色和服务帐户配置以匹配CLUSTER_1
中的配置。
重新平衡运行状况良好的 Kubernetes 集群上的数据节点。
通过编辑受更改影响的资源,重新配置MongoDBMultiCluster
资源以重新平衡运行状况良好的 Kubernetes 集群上的数据节点:
kubectl apply -n mongodb -f - <<EOF apiVersion: mongodb.com/v1 kind: MongoDBMultiCluster metadata: name: multi-replica-set spec: version: 6.0.0-ent type: ReplicaSet persistent: false duplicateServiceObjects: true credentials: my-credentials opsManager: configMapRef: name: my-project security: tls: ca: custom-ca clusterSpecList: - clusterName: ${MDB_CLUSTER_1_FULL_NAME} members: 4 - clusterName: ${MDB_CLUSTER_2_FULL_NAME} members: 3 EOF
使用 GitOps 工作流从故障中手动恢复
有关在具有 Argo CD 的 GitOps 工作流程中使用 MongoDB kubectl 插件 的示例 ,请参阅 GitOps 的多集群插件示例。
GitOps 恢复需要手动重新配置 基于角色的访问控制 使用.yaml
资源文件。要了解更多信息,请参阅了解 Kubernetes 角色和角色绑定。