Docs Menu
Docs Home
/ /
Alta disponibilidad

Elecciones del set de réplicas

Los sets de réplicas utilizan elecciones para determinar qué nodo del set se convertirá en primario. Los sets de réplicas pueden iniciar una elección en respuesta a una variedad de eventos, como:

En el siguiente diagrama, el nodo primario estuvo inactivo durante más tiempo que el configured timeout y activa el proceso de conmutación por error automática. Uno de los secundarios restantes llama a una elección para seleccionar un nuevo primario y reanudar automáticamente las operaciones normales.

Diagrama de una elección de un nuevo primario. En un set de réplicas de tres nodos con dos secundarios, el primario se vuelve inalcanzable. La pérdida de un primario activa una elección en la que uno de los secundarios se convierte en el nuevo primario
haga clic para ampliar

El set de réplicas no puede procesar operaciones de guardar hasta que la elección se complete con éxito. El set de réplicas puede seguir brindando servicio a queries de lectura si dichos queries están configurados para ejecutarse en los secundarios.

El tiempo medio para que un clúster elija un nuevo primario normalmente no debería exceder los 12 segundos, asumiendo el. replica configuration settings por defecto. Esto incluye el tiempo necesario para marcar el primario como no disponible y llamar y completar una elección. Se puede ajustar este periodo modificando la settings.electionTimeoutMillis opción de configuración de la replicación. Factores como la latencia de la red pueden extender el tiempo necesario para completar la elección del set de réplicas, lo que a su vez afecta la cantidad de tiempo que el clúster puede operar sin un primario. Estos factores dependen de la arquitectura particular del clúster.

La lógica de conexión de la aplicación debe incluir tolerancia para las conmutaciones por error automáticas y las elecciones posteriores. Los controladores de MongoDB pueden detectar la pérdida del nodo principal y reintentar automáticamente ciertas operaciones de guardado una sola vez, proporcionando un manejo adicional incorporado para conmutaciones por error automáticas y elecciones:

Los controladores compatibles habilitan las Escrituras reintentables por defecto

La replicación protocolVersion: 1 reduce el tiempo de conmutación por error del set de réplicas y acelera la detección de múltiples primarios simultáneos.

Se puede utilizar catchUpTimeoutMillis para priorizar entre conmutaciones por error más rápidas y la preservación de los w:1 guardados.

Para obtener más información sobre pv1, consultar Versión del protocolo del set de réplicas autogestionado.

Los nodos del set de réplicas envían latidos (pings) entre sí cada dos segundos. Si un latido no regresa en 10 segundos, los otros nodos marcan al nodo atrasado como inaccesible.

Después de que un set de réplicas tenga un primario estable, el algoritmo de elección hará un intento "con el mejor esfuerzo" para que el secundario con el priority más alto disponible convoque una elección. La prioridad de los nodos afecta tanto al momento como al resultado de las elecciones; los secundarios con mayor prioridad llaman elecciones relativamente antes que los secundarios con menor prioridad, y también tienen más probabilidades de ganar. Sin embargo, una instancia de menor prioridad puede ser elegida como primaria por períodos breves, incluso si hay una secundaria de mayor prioridad disponible. Los nodos del set de réplicas continúan convocando elecciones hasta que el nodo con la mayor prioridad disponible se convierte en el primario.

Los nodos con un valor de prioridad de 0 no pueden convertirse en primarios ni participar en elecciones. Para obtener más detalles, se puede consultar Nodos de sets de réplicas de prioridad 0.

MongoDB proporciona lecturas espejeadas para precalentar la caché de los miembros secundarios elegibles con los datos más recientemente accedidos. Con las lecturas espejeadas, el primario puede duplicar un subconjunto de operaciones que recibe y enviarlas a un subconjunto de secundarios elegibles. Precalentar la caché de un secundario puede ayudar a restaurar el rendimiento más rápidamente después de una elección.

Para aprender más, se puede consultar Lecturas espejeadas.

Con un set de réplicas distribuido, la pérdida de un centro de datos puede afectar la capacidad de los nodos restantes en otros centros de datos para elegir un primario.

Si es posible, se deben distribuir los nodos del set de réplicas en los centros de datos para maximizar la probabilidad de que incluso con la pérdida de un centro de datos, uno de los nodos restantes del set de réplicas pueda convertirse en el nuevo primario.

Tip

Una partición de red puede segregar un primario en una partición con una minoría de nodos. Cuando el nodo primario detecta que solo puede ver una minoría de nodos con derecho a voto en el set de réplicas, el nodo primario se degrada y se convierte en un nodo secundario. De forma independiente, un nodo de la partición que puede comunicarse con uno majority de los nodos con derecho a voto (incluido él mismo) lleva a cabo una elección para convertirse en el nuevo primario.

La configuración de los nodos del set de réplicas members[n].votes y el nodo state determinan si un nodo vota en una elección.

Aunque los nodos sin derecho a voto no votan en las elecciones, estos nodos mantienen copias de los datos del set de réplicas y pueden aceptar operaciones de lectura de las aplicaciones del cliente.

Debido a que un set de réplicas puede tener hasta 50 nodos, pero solo 7 nodos con derecho a voto, los nodos sin derecho a voto permiten que un set de réplicas tenga más de siete nodos.

Los nodos sin derecho a voto (es decir, votes es 0) deben tener priority de 0.

Por ejemplo, el siguiente set de réplicas de nueve nodos tiene siete nodos con derecho a voto y dos nodos sin derecho a voto.

Diagrama de un set de réplicas de 9 nodos con un máximo de 7 nodos con derecho a voto.

Un nodo sin derecho a voto tiene tanto votes como priority igual a 0:

{
"_id" : <num>,
"host" : <hostname:port>,
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 0,
"tags" : {
},
"secondaryDelaySecs" : Long(0),
"votes" : 0
}

Importante

No se debe alterar el número de votos para controlar qué nodos se convertirán en primarios. En su lugar, se debe modificar la opción members[n].priority. Solamente se altera el número de votos en casos excepcionales. Por ejemplo, para permitir más de siete nodos.

Para configurar un nodo sin derecho a voto, se puede consultar Configurar un nodo sin derecho a voto del set de réplicas autogestionado.

Volver

Alta disponibilidad

En esta página