Recuperar la base de datos de la aplicación si su conjunto de réplicas pierde la mayoría

Overview

En ciertas interrupciones graves del clúster de Kubernetes, la implementación del conjunto de réplicas de la base de datos de la aplicación podría perder la mayoría de los nodos. Por ejemplo, si tiene una implementación de la base de datos de la aplicación con dos nodos en cluster 1 y tres nodos en cluster 2, y cluster 2 sufre una interrupción, la implementación del conjunto de réplicas de la base de datos de la aplicación perderá la mayoría de nodos necesaria para elegir un nodo principal. Sin un nodo principal, el agente de MongoDB no puede reconfigurar un conjunto de réplicas.

Para habilitar la reprogramación de los nodos del conjunto de réplicas, el operador de Kubernetes debe reconfigurar forzosamente el conjunto de réplicas. Configuración de automatización del agente de MongoDB para habilitar la implementación de nodos de conjuntos de réplicas en los clústeres miembros restantes en buen estado. Para ello, el operador de Kubernetes establece el indicador replicaSets[n].force en la configuración del conjunto de réplicas. Este indicador indica al agente de MongoDB que fuerce al conjunto de réplicas a usar la versión actual (más reciente) de la configuración de automatización. El uso de este indicador permite al operador de Kubernetes reconfigurar el conjunto de réplicas en caso de que no se elija un nodo principal.

Recuperar la base de datos de la aplicación mediante una reconfiguración forzada

Para realizar una reconfiguración forzada de los nodos de la base de datos de la aplicación:

1. Cambiar el spec.applicationDatabase.clusterSpecList configuraciones para reconfigurar la implementación de la base de datos de la aplicación en clústeres de Kubernetes saludables para permitir que el conjunto de réplicas forme una mayoría de nodos saludables.

2. Reduzca los clústeres miembros de Kubernetes con errores a cero nodos y luego elimine esos clústeres del spec.applicationDatabase.clusterSpecList conjunto. No se permite eliminar una entrada sin reducirla primero. Esto garantiza que el conjunto de réplicas no cuente los nodos de la base de datos de la aplicación alojados en esos clústeres como miembros con derecho a voto del conjunto de réplicas. Por ejemplo, si tiene dos nodos cluster 1 en buen cluster 2 estado en y un 3 nodo con errores que contiene nodos, tendrá dos nodos en buen estado de un total de cinco miembros del conjunto de réplicas (2/ en5 buen estado). Añadir un nodo a cluster 1 da como resultado una proporción de 3/ de nodos en buen estado6 respecto al número de miembros del conjunto de réplicas. Para formar una mayoría en el conjunto de réplicas, tiene las siguientes opciones:

   • Agrega al menos dos nuevos nodos de set de réplicas a cluster 1 o un nuevo clúster de Kubernetes saludable. Esto logra una mayoría (4/7), con cuatro nodos en un set de réplicas de siete nodos.

   • Reduzca la escala de un clúster de Kubernetes fallido a cero nodos, elimine el clúster de y agregue al menos un nodo spec.applicationDatabase.clusterSpecList a cluster 1 para tener 3/3 nodos saludables en el StatefulSet del conjunto de réplicas.

3. Agregue la anotación "mongodb.com/v1.forceReconfigure": "true" en el nivel superior del recurso personalizado MongoDBOpsManager y asegúrese de que el valor "true" sea una cadena entre comillas.

   En función de esta anotación, el operador de Kubernetes realiza una reconfiguración forzada del conjunto de réplicas en el siguiente proceso de conciliación y escala los nodos del conjunto de réplicas de la base de datos de la aplicación según la configuración de implementación modificada.

   El operador de Kubernetes no puede determinar si los nodos del clúster de Kubernetes fallido funcionan correctamente. Por lo tanto, si no puede conectarse al servidor API del clúster de Kubernetes miembro fallido, ignora el clúster durante el proceso de reconciliación de los nodos del conjunto de réplicas de la base de datos de la aplicación.

   Esto significa que al reducir el tamaño de los nodos de la base de datos de la aplicación, se eliminan los procesos fallidos de la configuración del conjunto de réplicas. En los casos en que solo el servidor de API está inactivo, pero los nodos del conjunto de réplicas están en ejecución, el operador de Kubernetes no elimina los pods de los clústeres de Kubernetes fallidos.

   Para indicar que completó la reconfiguración forzada, el operador de Kubernetes agrega la clave de anotación, "mongodb.com/v1.forceReconfigurePerformed", con la marca de tiempo actual como valor.

   Importante

   El operador de Kubernetes solo realiza una reconfiguración forzada del conjunto de réplicas. Una vez que el conjunto de réplicas alcanza el estado de ejecución, el operador de Kubernetes agrega la "mongodb.com/v1.forceReconfigurePerformed" anotación para evitar forzar la reconfiguración nuevamente en el futuro. Por lo tanto, para volver a activar un nuevo evento de reconfiguración forzada, elimine una o ambas de las siguientes anotaciones del recurso en el archivo metadata.annotations del MongoDBOpsManager recurso personalizado.

   • "mongodb.com/v1.forceReconfigurePerformed"

   • "mongodb.com/v1.forceReconfigure"

4. Vuelva a aplicar la configuración para el recurso personalizado MongoDBOpsManager modificado en el operador de Kubernetes.