Para operaciones de lectura no asociadas con transacciones multi-documento, el nivel de consistencia de lectura "majority" garantiza que los datos leídos hayan sido reconocidos por la mayoría de los miembros del set de réplicas. Los documentos leídos son duraderos y está garantizado que no se revertirán.
Para las operaciones en transacciones multi-documento, la garantía proporcionada por "majority" del nivel de consistencia de lectura solo se aplica si la transacción se confirma con un nivel de confirmación de escritura (write concern) "mayoría". De lo contrario, el
"majority" el nivel de consistencia de lectura no garantiza la información leída en las transacciones.
Independientemente del nivel de consistencia de lectura, es posible que los datos más recientes de un nodo no reflejen la versión más reciente de los datos en el sistema.
Para obtener más información sobre lo que sucede si falla un primario, consulta Failover Automático.
Rendimiento
Cada miembro de un conjunto de réplicas mantiene, en memoria, una vista de los datos en el punto de compromiso mayoritario; el punto de compromiso mayoritario lo calcula el primario. Para satisfacer el nivel de consistencia de lectura "majority", el nodo devuelve datos de esta vista y es comparable en rendimiento con otros niveles de consistencia de lectura.
latencia
El nivel de consistencia de lectura "majority" no disminuye el rendimiento de las consultas; solo modifica lo que retorna al cliente. El nivel de consistencia de lectura "majority" permite que solo los datos almacenados de manera duradera en la mayoría de los nodos del set de réplicas se devuelvan al cliente. En comparación, las consultas con el nivel de consistencia de lectura "local" pueden devolver datos que pueden perderse en ciertos escenarios, como un rollback.
Disponibilidad
Nivel de consistencia de lectura "majority" está disponible para su uso con o sin sesiones y transacciones causalmente consistentes.
Advertencia
Si está utilizando una arquitectura de tres nodos de primario-secundario-árbitro (PSA), considere lo siguiente:
El nivel de confirmación de escritura
"majority"puede causar problemas de rendimiento si un secundario no está disponible o está retrasado. Para obtener consejos sobre cómo mitigar estos problemas, consulta Mitigar problemas de rendimiento con un set de réplicas de PSA autogestionado.Si está utilizando un
"majority"por defecto global y el nivel de confirmación de escritura (write concern) es menor que el tamaño de la mayoría, sus consultas pueden devolver datos obsoletos (no completamente replicados).
Ejemplo
Considera la siguiente cronología de una operación de escritura. Escribe 0 en un set de réplicas de tres nodos:
Nota
Para simplificar, el ejemplo supone:
Todas las escrituras anteriores a Escritura 0 se han replicado exitosamente en todos los miembros.
Write prev es la guardar anterior a Write 0.
No se produjeron otras escrituras después de Escritura 0.
Tiempo | Evento | Último guardar | Más reciente w: "mayoría" guardar |
|---|---|---|---|
t 0 | El primario aplica guardar 0 | Primary: Write 0 Secondary 1: Write prev Secondary 2: Write prev | Primary: Write prev Secondary 1: Write prev Secondary 2: Write prev |
t 1 | Secundario 1 aplica guardar 0 | Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write prev | Primary: Write prev Secondary 1: Write prev Secondary 2: Write prev |
t2 | Secundaria 2 aplica guardar 0 | Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0 | Primary: Write prev Secondary 1: Write prev Secondary 2: Write prev |
t 3 | El primario está al tanto de la replicación exitosa al secundario 1 y envía un acuse de recibo al cliente. | Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0 | Primary: Write 0 Secondary 1: Write prev Secondary 2: Write prev |
t 4 | El primario está al tanto de la replicación exitosa al secundario 2 | Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0 | Primary: Write 0 Secondary 1: Write prev Secondary 2: Write prev |
t 5 | El Secundario 1 recibe la notificación (a través del mecanismo regular de replicación) para actualizar su snapshot de su última w: guardar de "mayoría" | Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0 | Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write prev |
t 6 | El secundario 2 recibe un aviso (a través del mecanismo de replicación regular) para actualizar su instantánea de su escritura w: "mayoría" más reciente | Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0 | Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0 |
Luego, la siguiente tabla resume el estado de los datos que una operación de lectura con "majority" nivel de consistencia de lectura vería en el momento T.
Leer objetivo | Tiempo T | Estado de los datos |
|---|---|---|
Primario | Antes de t 3 | Los datos reflejan la escritura anterior |
Primario | Después de t 3 | Los datos reflejan guardar 0 |
Secundaria 1 | Antes de t 5 | Los datos reflejan la escritura anterior |
Secundaria 1 | Después de t 5 | Los datos reflejan guardar 0 |
Secundario 2 | Antes o en t 6 | Los datos reflejan la escritura anterior |
Secundario 2 | Después de t 6 | Los datos reflejan guardar 0 |
Compatibilidad con el motor de almacenamiento
"majority" La inquietud leída está disponible para el motor de almacenamiento WiredTiger.
Leer Preocupación y Transacciones "majority"
Nota
La preocupación de lectura se configura a nivel de transacción, no a nivel de operación individual. Para configurar la preocupación de lectura para transacciones, consulte Transacciones y preocupación de lectura.
Para operaciones en transacciones multidocumento, la solicitud de lectura "majority" solo ofrece garantías si la transacción se confirma con la solicitud de escritura "mayoritaria". De lo contrario, la "majority" solicitud de lectura no ofrece garantías sobre los datos leídos en las transacciones.
Leer Preocupación y Agregación "majority"
Puede especificar el nivel de consistencia de lectura "majority" para una agregación que incluya una etapa $out.
Lee tus propios guardados
Se pueden utilizar sesiones con coherencia causal para leer tus propias escrituras, si las escrituras solicitan reconocimiento.
Sets de réplicas primario-secundario-árbitro
A partir de MongoDB 5.0, enableMajorityReadConcern y --enableMajorityReadConcern no se pueden cambiar y siempre se establecen en true debido a mejoras en el motor de almacenamiento.
En versiones anteriores de MongoDB, enableMajorityReadConcern y --enableMajorityReadConcern son configurables y se pueden establecer en false para evitar que la presión sobre la caché de almacenamiento inmovilice una implementación con una arquitectura de primario-secundario-árbitro (PSA) de tres miembros.
Si está utilizando una arquitectura de tres nodos de primario-secundario-árbitro (PSA), considere lo siguiente:
El nivel de confirmación de escritura
"majority"puede causar problemas de rendimiento si un secundario no está disponible o está retrasado. Para obtener consejos sobre cómo mitigar estos problemas, consulta Mitigar problemas de rendimiento con un set de réplicas de PSA autogestionado.Si está utilizando un
"majority"por defecto global y el nivel de confirmación de escritura (write concern) es menor que el tamaño de la mayoría, sus consultas pueden devolver datos obsoletos (no completamente replicados).