Docs Menu
Docs Home
/ /

Nivel de consistencia de lectura "mayoría"

"majority"

Para operaciones de lectura no asociadas con Entransacciones multidocumento, "majority" la preocupación de lectura garantiza que la mayoría de los miembros del conjunto de réplicas hayan reconocido los datos leídos. Los documentos leídos son duraderos y se garantiza su inalterabilidad.

Para operaciones en transacciones multidocumento, la solicitud de lectura "majority" ofrece sus garantías solo si la transacción se confirma con la solicitud de escritura "mayoría". De lo contrario, "majority" La lectura no ofrece garantías sobre los datos leídos 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 qué sucede si falla un servidor principal,consulte Conmutación por error automática.

Cada miembro del conjunto de réplicas mantiene, en memoria, una vista de los datos en el punto de confirmación mayoritaria; dicho punto lo calcula el nodo principal. Para cumplir con la solicitud de lectura "majority", el nodo devuelve datos de esta vista y su rendimiento es comparable al de otras solicitudes de lectura.

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.

La lectura de preocupación está disponible para su uso con o sin sesiones y transacciones causalmente consistentes."majority"

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 valor "majority" predeterminado global y el problema de escritura es menor que el tamaño de la mayoría, sus consultas pueden devolver datos obsoletos (no completamente replicados).

Considere la siguiente línea de tiempo de una operación de 0 escritura: Escribir en un conjunto de réplicas de tres miembros:

Nota

Para simplificar, el ejemplo supone:

  • Todas las escrituras anteriores a Escritura se han replicado exitosamente en todos los 0 miembros.

  • Escribir anterior es la escritura anterior a 0 Escribir.

  • No se han producido otras escrituras después de 0 Escritura.

Cronología de una operación de guardar en un set de réplicas de tres nodos
Tiempo
Evento
Escritura más reciente
Más reciente w: "mayoría" escribe

t 0

Primario aplica Escribir 0

Primary: Write 0
Secondary 1: Write prev
Secondary 2: Write prev
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev

el 1

El secundario aplica 1 escritura 0

Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write prev
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev

el 2

El secundario aplica 2 escritura 0

Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev

el 3

El servidor principal es consciente de la replicación exitosa al 1 servidor secundario 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

el 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

el 5

El secundario 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 1 reciente

Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write prev

el 6

El secundario 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 2 reciente

Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0

Luego, las siguientes tablas resumen el estado de los datos que una operación de lectura con interés de lectura "majority" vería en el T momento.

Cronología de una operación de escritura en un conjunto de réplicas de tres miembros.
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 la escritura 0

Secundario 1

Antes de t 5

Los datos reflejan la escritura anterior

Secundario 1

Después de t 5

Los datos reflejan la escritura 0

Secundario 2

Antes o en t 6

Los datos reflejan la escritura anterior

Secundario 2

Después de t 6

Los datos reflejan la escritura 0

"majority" La inquietud leída está disponible para el motor de almacenamiento WiredTiger.

Tip

El comandoserverStatusdevuelve el campostorageEngine.supportsCommittedReads, que indica si el motor de almacenamiento admite la lectura "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.

Puede especificar el nivel de preocupación de lectura para una "majority" $out agregación que incluya una etapa.

Se pueden utilizar sesiones con coherencia causal para leer tus propias escrituras, si las escrituras solicitan reconocimiento.

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 son configurables y se pueden establecer --enableMajorityReadConcern en false para evitar que la presión de la memoria caché de almacenamiento inmovilice una implementación con una arquitectura de árbitro primario-secundario (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 valor "majority" predeterminado global y el problema de escritura es menor que el tamaño de la mayoría, sus consultas pueden devolver datos obsoletos (no completamente replicados).

Volver

"disponible"

En esta página