Recuperar Ops Manager si falla el clúster del operador

Esta versión de la documentación está archivada y ya no se admite, y el operador de Kubernetes de MongoDB Enterprise está obsoleto. El nuevo El Operador de Controladores para Kubernetes de MongoDB reemplaza al Operador de Kubernetes Empresarial de MongoDB. La primera versión del Operador de Controladores para Kubernetes es funcionalmente equivalente a la última versión del Operador de Kubernetes Empresarial,1.33 v. Para obtener más información sobre este cambio y orientación sobre la migración al nuevo Operador, consulte las notas de la versión de la primera versión. No habrá futuras versiones del Operador de Kubernetes Empresarial de MongoDB. Cada versión alcanzará el final de su vida útil según el plazo de un año vigente. Política de soporte. Migre al operador de controladores para Kubernetes para obtener soporte continuo.

En el caso de que el clúster de Kubernetes que aloja el operador de Kubernetes y la aplicación Ops Manager falle, puede recuperar manualmente el clúster del operador y la aplicación Ops Manager.

Para restaurar el estado de ejecución anterior de Ops Manager, configure un mecanismo de copia de seguridad periódica para los recursos de Ops Manager y la base de datos de la aplicación. El operador de Kubernetes necesita estos recursos para administrar la implementación de la aplicación de Ops Manager.

Recuperar el operador de Kubernetes y Ops Manager

Para recuperar el operador de Kubernetes y el administrador de operaciones, restaure el recurso del administrador de operaciones en un nuevo clúster de Kubernetes:

Configurar el operador de Kubernetes en un nuevo clúster.

Siga las instrucciones para instalar el operador de Kubernetes en un nuevo clúster de Kubernetes.

Nota

Si planea reutilizar un clúster miembro, asegúrese de que existan la cuenta de servicio y el rol adecuados. Estos valores pueden superponerse y tener diferentes permisos entre el clúster del operador y el clúster miembro.

Para ver el rol apropiado requerido para el operador de Kubernetes, consulte el ejemplo en el repositorio público.

Recupere los recursos respaldados del recurso Ops Manager fallido.

Copie la especificación del objeto para el recurso de Ops Manager que falló y recupere los siguientes recursos, reemplazando el texto del marcador de posición con el nombre y el espacio de nombres de su recurso de Ops Manager específico.

Tipo de recurso	Values
Misterios	`<om-name>-db-om-password` `<om-name>-db-agent-password` `<om-name>-db-keyfile` `<om-name>-db-om-user-scram-credentials` `<om-namespace>-<om-name>-admin-key` `<om-name>-admin-secret` `<om-name>-gen-key` TLS secretos del certificado (opcional)
Mapas de configuración	`<om-name>-db-cluster-mapping` `<om-name>-db-member-spec` CA personalizada para certificados TLS (opcional)
OpsManager	`<om-name>`

Luego, pegue la especificación que copió en un archivo nuevo y configure el nuevo recurso con los valores anteriores. Para obtener más información, consulte Implementar un recurso de Ops Manager.

Vuelva a aplicar el recurso Ops Manager al nuevo clúster.

Utilice el siguiente comando para aplicar el recurso actualizado:

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

Para comprobar el estado de tu recurso de Ops Manager, utiliza el siguiente comando:

kubectl get om -o yaml -w

Una vez que el clúster de operadores alcanza un estado Running, puede volver a escalar la base de datos de la aplicación según la distribución deseada de clústeres miembros.

En este punto, el operador de Kubernetes recientemente restaurado debe asumir la administración de la base de datos de aplicaciones existente.

El ConfigMap utilizado para crear el proyecto inicial.
Los secretos utilizados en la instancia anterior del operador de Kubernetes.
El MongoDB MongoDBMulticluster recurso personalizado o en su último estado disponible en el clúster de origen, incluidas todas las anotaciones agregadas por el operador de Kubernetes durante su ciclo de vida.

Nota

Si el conjunto de réplicas de la base de datos de la aplicación ha perdido algunos nodos y no puede formar una mayoría de votos, se fuerza su reconfiguración. Esto añade nuevos nodos que formarán una mayoría de votos, lo que permitirá al conjunto de réplicas elegir un nodo principal.

Volver

Recuperar clúster disponible

Recuperar el conjunto de réplicas mayoritarias perdidas