Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

Nivel de consistencia de lectura "mayoría"

"majority"

Para las operaciones de lectura no asociadas con transacción 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 se garantiza que no se revertirán.

Para operaciones en transacciones de múltiples documentos, la garantía de lectura "majority" solo se aplica si la transacción se confirma con la garantía de escritura"mayoría". De lo contrario, la garantía de lectura "majority" no ofrece ninguna garantía 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 lo que sucede si falla un primario, consulta Failover Automático.

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.

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 función Read concern "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 (write concern) "majority" puede causar problemas de rendimiento si un secundario no está disponible o está retrasado. Para obtener consejos sobre cómo mitigar estos problemas, consulte Mitigar problemas de rendimiento en sets de réplicas autogestionados.

  • Si está utilizando un valor predeterminado global "majority" y la preocupación de escritura es menor que el tamaño de la mayoría, sus consultas pueden devolver datos obsoletos (no completamente replicados).

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 asume:

  • Todas las operaciones de escritura anteriores a la escritura 0 se han replicado correctamente en todos los nodos.

  • Write prev es la guardar anterior a Write 0.

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

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

t 0

El primario aplica guardar 0

Primario: Guardar 0
Secundario 1: Guardar prev
Secundario 2: Guardar prev

Primario: Guardar prev
Secundario 1: Guardar prev
Secundario 2: Guardar prev

t 1

Secundario 1 aplica guardar 0

Primario: guardar 0
Secundario 1: guardar 0
Secundario 2: guardar prev

Primario: Guardar prev
Secundario 1: Guardar prev
Secundario 2: Guardar prev

t 2

Secundaria 2 aplica guardar 0

Primario: Guardar 0
Secundario 1: Guardar 0
Secundario 2: Guardar 0

Primario: Guardar prev
Secundario 1: Guardar prev
Secundario 2: Guardar prev

t 3

Principal está al tanto de la replicación exitosa a Secundario 1 y envía acuse de recibo al cliente

Primario: Guardar 0
Secundario 1: Guardar 0
Secundario 2: Guardar 0

Primario: Guardar 0
Secundario 1: Guardar prev
Secundario 2: Guardar prev

t 4

El primario está al tanto de la replicación exitosa del secundario 2

Primario: Guardar 0
Secundario 1: Guardar 0
Secundario 2: Guardar 0

Primario: Guardar 0
Secundario 1: Guardar prev
Secundario 2: Guardar 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"

Primario: Guardar 0
Secundario 1: Guardar 0
Secundario 2: Guardar 0

Primario: guardar 0
Secundario 1: guardar 0
Secundario 2: guardar prev

t 6

El secundario 2 recibe un aviso (a través del mecanismo de replicación regular) para actualizar su snapshot de su escritura más reciente de "mayoría".

Primario: Guardar 0
Secundario 1: Guardar 0
Secundario 2: Guardar 0

Primario: Guardar 0
Secundario 1: Guardar 0
Secundario 2: Guardar 0

A continuación, las siguientes tablas resumen el estado de los datos que una operación de lectura con "majority" preocupación de lectura vería en el momento T.

Cronograma de una operación de escritura en un set de réplicas de tres nodos.
Leer destino
Tiempo T
Estado de los datos

Primario

Antes de t 3

Los datos reflejan guardar prev

Primario

Después de t 3

Los datos reflejan guardar 0

Secundaria 1

Antes de t 5

Los datos reflejan guardar prev

Secundaria 1

Luego de t 5

Los datos reflejan guardar 0

Secundario 2

Antes o en t 6

Los datos reflejan guardar prev

Secundario 2

Después de t 6

Los datos reflejan guardar 0

La función Read concern "majority" está disponible para el motor de almacenamiento WiredTiger.

Tip

El comando serverStatus retorna el campo storageEngine.supportsCommittedReads, que indica si el motor de almacenamiento soporta el nivel de consistencia de lectura "majority".

Nota

Estableces el nivel de consistencia de lectura a nivel de transacción, no a nivel de operación individual. Para establecer el nivel de consistencia de lectura para las transacciones, consulte Transacciones y nivel de consistencia de lectura.

Para operaciones en transacciones de múltiples documentos, la garantía de lectura "majority" solo se aplica si la transacción se confirma con la garantía de escritura"mayoría". De lo contrario, la garantía de lectura "majority" no ofrece ninguna garantía sobre los datos leídos en las transacciones.

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

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 --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 (write concern) "majority" puede causar problemas de rendimiento si un secundario no está disponible o está retrasado. Para obtener consejos sobre cómo mitigar estos problemas, consulte Mitigar problemas de rendimiento en sets de réplicas autogestionados.

  • Si está utilizando un valor predeterminado global "majority" y la preocupación de escritura es menor que el tamaño de la mayoría, sus consultas pueden devolver datos obsoletos (no completamente replicados).