Un conjunto de réplicas en MongoDB es un grupo de mongod Procesos que proporcionan redundancia y alta disponibilidad. Los miembros de un conjunto de réplicas son:
- Primario
- El primario recibe todas las operaciones de guardado.
- Secundarios
- Los secundarios replican las operaciones del primario para mantener un conjunto de datos idéntico. Los secundarios pueden tener configuraciones adicionales para perfiles de uso especiales. Por ejemplo, los secundarios pueden ser no votantes o de prioridad 0.
La configuración mínima recomendada para un Set de réplicas es un Set de réplicas de tres nodos con tres nodos que contengan datos: un primario y dos secundarios. En algunas circunstancias (como si tienes un primario y un secundario pero las limitaciones de costo impiden añadir otro secundario), puedes optar por incluir un árbitro. Un árbitro participa en elecciones pero no almacena datos (es decir, no proporciona redundancia de datos).
Un set de réplicas puede tener hasta 50 miembros, pero solo 7 miembros votantes.
Primario
El primario es el único nodo del set de réplicas que recibe operaciones de guardar. MongoDB aplica operaciones de escritura en el primario y luego registra las operaciones en el oplog del primario. Los miembros secundarios replican este registro y aplican las operaciones a sus conjuntos de datos.
En el siguiente set de réplicas de tres nodos, el primario acepta todas las operaciones de guardar. Luego, los secundarios replican el oplog para aplicarlo a sus conjuntos de datos.
Todos los miembros del set de réplicas pueden aceptar operaciones de lectura. Sin embargo, por defecto, una aplicación dirige sus operaciones de lectura al miembro primario. Consultar preferencia de lectura para obtener más información sobre cómo cambiar el comportamiento de lectura por defecto.
El set de réplicas puede tener como máximo un primario. [2] Si el primario actual se vuelve no disponible, una elección determina el nuevo primario. Consultar Elecciones de set de réplicas para más detalles.
Secundarios
Un secundario mantiene una copia del conjunto de datos del primario. Para replicar datos, un secundario aplica operaciones del oplog del primario a su propio conjunto de datos en un proceso asincrónico. [1] Un set de réplicas puede tener uno o más secundarios.
El siguiente Set de réplicas de tres nodos tiene dos nodos secundarios. Los secundarios replican el oplog del primario y aplican las operaciones a sus conjuntos de datos.
Aunque los clientes no pueden guardar datos en los secundarios, pueden leer datos de los miembros secundarios. Consultar Preferencia de lectura para obtener más información sobre cómo los clientes dirigen las operaciones de lectura a los sets de réplicas.
Un secundario puede convertirse en primario. Si el primario actual deja de estar disponible, el set de réplicas lleva a cabo una elección para decidir cuál de los secundarios se convierte en el nuevo primario.
Consultar Elecciones de set de réplicas para más detalles.
Puede configurar un miembro secundario para un propósito específico. Puede configurar un secundario para:
Evitar que se convierta en un nodo primario en una elección, lo que permite residir en un centro de datos secundario o servir como reserva en frío. Consultar Miembros del set de réplicas con prioridad 0.
Impedir que las aplicaciones lean de él, lo que permite ejecutar aplicaciones que requieren una separación del tráfico normal. Consultar Miembros ocultos del set de réplicas.
Mantener un "snapshot" histórico en ejecución para usarlo en la recuperación de ciertos errores, como bases de datos borradas involuntariamente. Consultar Miembros retrasados del set de réplicas.
| [1] | Los miembros secundarios de un set de réplicas ahora registran entradas de oplog que tardan más que el umbral de una operación lenta en aplicarse. Estos mensajes lentos del oplog:
|
Árbitro
En algunas circunstancias (como cuando se tiene un primario y un secundario, pero las limitaciones de costo impiden añadir otro secundario), se puede optar por añadir un árbitro al set de réplicas. Un árbitro participa en elecciones para primario, pero un árbitro no tiene una copia del conjunto de datos y no puede convertirse en primario.
Un árbitro tiene exactamente 1 voto en la elección. Por defecto, un árbitro tiene la prioridad 0.
Importante
No ejecutar un árbitro en sistemas que también sean los hosts de los miembros primarios o secundarios del set de réplicas.
Advertencia
El uso de una arquitectura de primario-secundario-árbitro (PSA) para fragmentos en un clúster puede provocar una pérdida de disponibilidad si un secundario que almacena datos no está disponible. Un clúster PSA se diferencia de un set de réplicas típico: en un clúster fragmentado, los fragmentos realizan w: majority operaciones de nivel de confirmación de escritura que no pueden completarse si los miembros restantes del clúster necesarios para confirmar una operación tienen un árbitro.
Para agregar un árbitro, consultar Agregar un árbitro a un set de réplicas autogestionado.
Para conocer las consideraciones sobre el uso de un árbitro, consultar Árbitro de set de réplicas.
| [2] | En algunas circunstancias, dos nodos en un set de réplicas pueden creer transitoriamente que son los primarios, pero como mucho, uno de ellos podrá completar escrituras con el nivel de confirmación de escritura { w:
"majority" }. El nodo que puede completar { w: "majority" } escrituras es el primario actual, y el otro nodo es un ex primario que aún no ha reconocido su descenso de categoría, típicamente debido a una partición de red. Cuando esto ocurre, los clientes que se conectan al antiguo primario pueden observar la presencia de datos obsoletos a pesar de haber solicitado la preferencia de lectura primary, y las nuevas escrituras en el antiguo primario eventualmente se revertirán. |