Recuperar la base de datos de la aplicación si pierde la mayoría

Overview

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

Para permitir la reprogramación de los nodos del conjunto de réplicas, el operador de Kubernetes debe reconfigurar forzosamente la configuración de automatización del agente de MongoDB para habilitar el despliegue de nodos del conjunto de réplicas en los clústeres miembros restantes que estén 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.

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. Cambie la configuración de spec.applicationDatabase.clusterSpecList para reconfigurar la implementación de la base de datos de la aplicación en clústeres de Kubernetes saludables y permitir que el set de réplicas forme una mayoría de nodos saludables.

2. Escale a cero los nodos de los clústeres nodos de Kubernetes que han fallado y, a continuación, remueva esos clústeres del spec.applicationDatabase.clusterSpecList. No se admite remover una entrada sin escalarla primero. Esto asegura que el set de réplicas no cuente 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 saludables en cluster 1 y un cluster 2 fallido que contiene 3 nodos, tienes dos nodos saludables de un total de cinco miembros del set de réplicas (2/5 saludables). Agregar un nodo a cluster 1 resulta en tener una proporción de 3/6 nodos saludables en relación con el número de miembros en el set de réplicas. Para formar una mayoría en un 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.

   • Escale a cero los nodos de un clúster fallido de Kubernetes, remueva el clúster del spec.applicationDatabase.clusterSpecList y añada 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 una única 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 añade la anotación "mongodb.com/v1.forceReconfigurePerformed" para evitar forzar la reconfiguración nuevamente en el futuro. Por lo tanto, para reactivar un nuevo evento de reconfiguración forzada, elimine una o ambas de las siguientes anotaciones del recurso, en 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.