Elecciones y conmutación por error automática

La conmutación por error automática es la capacidad de un conjunto de réplicas de MongoDB para recuperarse del fallo del nodo primario sin intervención humana. Cuando el primario deja de estar accesible, los miembros restantes eligen automáticamente un nuevo primario, normalmente en un plazo de 10 a 30 segundos, de modo que las aplicaciones solo experimentan una breve pausa en lugar de una interrupción total.

Los miembros del conjunto de réplicas intercambian continuamente mensajes de heartbeat cada 2 segundos. Si un miembro no recibe una respuesta de heartbeat dentro de electionTimeoutMillis (10 segundos de forma predeterminada), marca al miembro silencioso como inaccesible. Si el miembro ausente es el primario, los miembros restantes que cumplen los requisitos inician una elección.

Una elección se inicia en tres situaciones: 1) el primario deja de estar accesible (por una partición de red o un fallo), 2) un usuario hace que el primario renuncie manualmente mediante rs.stepDown() o 3) se incorpora un secundario con mayor prioridad y el primario actual tiene una prioridad menor. Solo los miembros con votes: 1 y priority > 0 pueden convertirse en el nuevo primario.

Las elecciones de MongoDB utilizan un protocolo inspirado en el consenso de Raft. Cada candidato incrementa su contador term y solicita votos a los demás miembros. Un candidato gana si recibe los votos de la mayoría de los miembros con derecho a voto. Se prefiere al candidato con el oplog más actualizado (el optime más alto), lo que evita la pérdida de datos al garantizar que el nuevo primario haya visto todas las escrituras confirmadas.

Un candidato necesita los votos de más de la mitad de todos los miembros con derecho a voto (no solo de los que están accesibles en ese momento). En un conjunto de 3 miembros con 3 votos, la mayoría es 2. Esto significa que, si 2 miembros dejan de funcionar simultáneamente, el miembro superviviente no puede elegirse a sí mismo: estaría operando con datos obsoletos y no tendría forma de saber si los otros dos miembros tienen escrituras más recientes.

La elección se desarrolla de la siguiente manera: 1) un secundario detecta que el primario ha desaparecido después del tiempo de espera. 2) cambia al estado CANDIDATE. 3) envía mensajes RequestVote a todos los demás miembros. 4) los miembros conceden sus votos si el oplog del candidato está al menos tan actualizado como el suyo y aún no han votado. 5) el ganador cambia al estado PRIMARY y comienza a aceptar escrituras.

Durante la ventana de elección (normalmente de unos segundos), se rechazan las escrituras porque no hay ningún primario. El controlador de MongoDB almacena en búfer las operaciones de escritura y las reintenta una vez elegido el nuevo primario. Con las escrituras reintentables habilitadas (la configuración predeterminada en los controladores modernos), los errores transitorios de elección se reintentan de forma transparente una vez.

Cuando varios candidatos están igual de actualizados, la priority deshace el empate: gana el miembro con mayor prioridad. Si un secundario con mayor prioridad vuelve a incorporarse después de haber estado desconectado, activará una nueva elección para asumir el rol de primario. Establecer la prioridad en 0 excluye permanentemente a un miembro de la posibilidad de convertirse en primario.

En una partición de red, los miembros de un lado de la división no pueden comunicarse con los del otro. El lado que tiene la mayoría de los votos puede elegir un primario; el lado minoritario entra en un estado de solo lectura. Esto evita una situación de split-brain en la que dos miembros creen simultáneamente que son el primario y aceptan escrituras en conflicto.

Puede supervisar las elecciones y las conmutaciones por error examinando el registro de MongoDB o consultando la configuración de system.replset. Atlas proporciona alertas en tiempo real para los eventos de elección. En los registros de su aplicación, observará picos de MongoNotPrimaryError o MongoNetworkError durante una elección; las escrituras reintentables gestionan estos errores automáticamente.

Para minimizar el tiempo de conmutación por error: 1) mantenga los conjuntos de réplicas con un número impar de miembros (3 o 5) para evitar la necesidad de árbitros. 2) use un write concern de mayoría para garantizar que el secundario elegido tenga todas las escrituras confirmadas. 3) minimice el retraso del oplog proporcionando un tamaño de oplog suficiente. 4) coloque los miembros del conjunto de réplicas en la misma región para obtener heartbeats de baja latencia.

En esta lección aprendió que: los heartbeats detectan el fallo del primario en un plazo de electionTimeoutMillis (10 s de forma predeterminada), el candidato con el oplog más actualizado y la prioridad más alta gana la elección y las escrituras reintentables permiten que las aplicaciones superen de forma transparente las breves ventanas de elección. A continuación, veremos los write concerns y cómo controlar la durabilidad de las escrituras en el conjunto de réplicas.