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 forzar la reconfiguración de automatización del agente de MongoDB para permitir la implementación de nodos del conjunto de réplicas en los clústeres miembros restantes que funcionan correctamente. Para lograrlo, 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. Usar 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. 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. Elimine los clústeres de Kubernetes fallidos de spec.applicationDatabase.clusterSpecList o reduzca la escala de los clústeres miembros de Kubernetes fallidos. De esta forma, el conjunto de réplicas no cuenta los nodos de la base de datos de aplicaciones alojados en esos clústeres como miembros con derecho a voto. Por ejemplo, si tiene dos nodos en buen estado en cluster 1 y un cluster 2 3 nodo fallido 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 36 de / de nodos en buen estado 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.

   • 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" 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 metadata.annotations.para el 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.