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

Overview

En ciertos casos graves de interrupciones del servicio en el clúster de Kubernetes, la implementación del set de réplicas de la base de datos de la aplicación podría perder la mayoría de los nodos del set de réplicas. Por ejemplo, si tienes una implementación de 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 para el MongoDB Agent, con el fin de habilitar la implementación de nodos de conjuntos de réplicas en los clústeres de miembros saludables restantes. Para lograr esto, el Operador de Kubernetes establece el replicaSets[n].force bandera en la configuración del set de réplicas. La bandera instruye al MongoDB Agent para forzar que un set de réplicas utilice la versión actual (más reciente) de la Configuración de Automatización. Utilizar la bandera permite al operador de Kubernetes reconfigurar el set de réplicas en caso de que no se elija un nodo primario.

Recupere 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. Remueve los clústeres de Kubernetes fallidos de la spec.applicationDatabase.clusterSpecList o escala los clústeres nodo de Kubernetes fallidos. De este modo, el set de réplicas no cuenta los nodos de la base de datos de la aplicación alojados en esos clústeres como miembros votantes del set de réplicas. Por ejemplo, al tener dos nodos sanos en cluster 1 y un cluster 2 fallido que contiene 3 nodos, tienes dos nodos sanos de un total de cinco miembros del set de réplicas (2/5 sanos). Agregar un nodo a cluster 1 da como resultado una proporción de 3/6 de nodos sanos respecto al número de miembros en el set de réplicas. Para formar una mayoría en el set de réplicas, tienes 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.

   • Escalar un clúster de Kubernetes fallido a cero nodos, o remover el clúster del spec.applicationDatabase.clusterSpecList por completo, y agregar al menos un nodo a cluster 1 para tener 3/3 nodos saludables en el StatefulSet del set de réplicas.

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

   Basándose en esta anotación, el operador de Kubernetes realiza una reconfiguración forzada del set de réplicas en el siguiente proceso de reconciliación y escala los nodos del set de réplicas de la base de datos de la aplicación de acuerdo con la configuración de implementación cambiada.

   El operador de Kubernetes no tiene medios para determinar si los nodos en el clúster de Kubernetes fallido están saludables. Por lo tanto, si el operador de Kubernetes no puede conectarse al servidor API del clúster nodo fallido de Kubernetes, el operador de Kubernetes 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 el escalado a la baja de los nodos de la base de datos de la aplicación remueve los procesos fallidos de la configuración del set de réplicas. En los casos en que solo el servidor API no funciona, pero los nodos del set de réplicas están en ejecución, el operador de Kubernetes no remueve los pods de los clústeres 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.