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 del servicio, la implementación del set de réplicas de la base de datos de la aplicación perderá la mayoría de nodos necesaria para elegir un primario. Sin un primario, el MongoDB Agent no puede reconfigurar un conjunto de réplicas.

Para habilitar la reprogramación de los nodos del set de réplicas, el operador de Kubernetes debe reconfigurar forzosamente el 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 ajustes de configuración para reconfigurar la implementación de la base de datos de la aplicación en clústeres saludables de Kubernetes, permitiendo que el set 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 Kubernetes agrega la clave de anotación, "mongodb.com/v1.forceReconfigurePerformed", con la marca de tiempo actual como valor.

   Importante

   El operador de Kubernetes realiza solo una reconfiguración forzada del set de réplicas. Después de que el set de réplicas alcance un estado de ejecución, el Kubernetes operador añade la anotación "mongodb.com/v1.forceReconfigurePerformed" para evitar que se fuerce la reconfiguración en el futuro. Por lo tanto, para volver a activar un nuevo evento de reconfiguración forzada, elimina uno o ambos de los siguientes annotations del recurso, en el metadata.annotations para el recurso personalizado MongoDBOpsManager.

   • "mongodb.com/v1.forceReconfigurePerformed"

   • "mongodb.com/v1.forceReconfigure"

4. Vuelve a aplicar la configuración para el recurso personalizado cambiado MongoDBOpsManager en el Operador de Kubernetes.