Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

readConcern

Usa el readConcern opción para controlar la coherencia y el aislamiento de los datos leídos de sets de réplicas y clústeres.

Mediante el uso eficaz de nivel de confirmación de escritura (write concern) y nivel de consistencia de lectura, puedes ajustar el nivel de garantías de coherencia y disponibilidad. Por ejemplo, puedes esperar garantías de coherencia más sólidas o relajar los requisitos de coherencia para una mayor disponibilidad.

Los conjuntos de réplicas y los clústeres particionados soportan un nivel de consistencia de lectura global por defecto. Las operaciones sin un nivel de consistencia de lectura explícito heredan la global por defecto. Consulte setDefaultRWConcern para obtener más información.

Los siguientes niveles de consistencia de lectura están disponibles:

level
Descripción

La consulta devuelve datos desde la instancia sin garantía de que los datos hayan sido escritos en la mayoría de los miembros del set de réplicas. Es posible que los datos se reviertan.

Por defecto para las lecturas en el primario y los secundarios.

Disponibilidad: el nivel de consistencia de lectura "local" está disponible con o sin sesiones y transacciones causalmente consistentes.

Para obtener más información, consulte la página de referencia "local".

La consulta devuelve datos desde la instancia sin garantía de que los datos hayan sido escritos en la mayoría de los miembros del set de réplicas. Es posible que los datos se reviertan.

Disponibilidad: el nivel de consistencia de lectura "available" está No disponible para su uso con sesiones y transacciones causalmente coherentes.

Para los clústeres fragmentados, el nivel de consistencia de lectura "available" proporciona las lecturas de latencia más bajas posibles entre los diversos niveles de consistencia de lectura. Sin embargo, esto se produce a costa de la coherencia, ya que "available" nivel de consistencia de lectura puede devolver los documentos huérfanos al leer de una colección fragmentada. Para evitar el riesgo de devolver documentos huérfanos al leer de colecciones fragmentadas, utiliza un nivel de consistencia de lectura diferente, como el nivel de consistencia de lectura "local".

Para obtener más información, consulte la página de referencia "available".

La query devuelve los datos reconocidos por la mayoría de los miembros del set de réplicas. Los documentos devueltos son duraderos, incluso si se produce un fallo.

Para cumplir con el nivel de consistencia de lectura "majority", el set de réplicas devuelve los datos de su vista en memoria en el punto de confirmación mayoritaria. El nivel de consistencia de lectura "majority" tiene un rendimiento comparable al de otras preocupaciones de lectura.

Disponibilidad: el nivel de consistencia de lectura "majority" está disponible con o sin sesiones y transacciones causalmente consistentes.

Requisitos: Los sets de réplicas deben utilizar el motor de almacenamiento WiredTiger.

Para transacciones multi-documento, el nivel de consistencia de lectura "majority" ofrece garantías solo si la transacción se confirma con nivel de confirmación de escritura (write concern) "majority". De lo contrario, "majority" no ofrece garantías sobre la lectura de datos en las transacciones.

Para obtener más información, consulte la página de referencia "majority".

La query devuelve datos que reflejan todos los guardados exitosos reconocidos por mayoría que se completaron antes del inicio de la operación de lectura. La query puede esperar que los guardados concurrentes se propaguen a la mayoría de los sets de réplicas antes de devolver los resultados.

Si la mayoría de los miembros de tu set de réplicas fallan y se reinician después de la operación de lectura, los documentos devueltos son duraderos si writeConcernMajorityJournalDefault está configurado al valor por defecto de true.

Con writeConcernMajorityJournalDefault configurado en false, MongoDB no espera a que las escrituras w: "majority" se registren en la bitácora en disco antes de confirmar las escrituras. Por lo tanto, "majority" las operaciones de escritura podrían revertirse en caso de una pérdida transitoria (p. ej., caída y reinicio) de la mayoría de los nodos en un set de réplicas determinado.

Disponibilidad:

  • El nivel de consistencia de lectura "linearizable" no está disponible para su uso con sesiones y transacciones causalmente coherentes.

  • Solo puede especificar el nivel de consistencia de lectura linealizable para las operaciones de lectura en el primary.

No puede utilizar la etapa $out o la etapa $merge junto con el nivel de consistencia de lectura "linearizable". Es decir, si especifica el nivel de consistencia de lectura "linearizable" para db.collection.aggregate(), no puede incluir ninguna de las dos etapas en el pipeline.

Requisitos:

Las garantías del nivel de consistencia de lectura linealizable solo se aplican si las operaciones de lectura especifican un filtro de query que identifique de forma única un solo documento. Además, si no se cumple ninguno de los siguientes criterios, es posible que el nivel de consistencia de lectura linealizable no lea desde una snapshot coherente, lo que resultará en que no se devuelva un documento que coincida con el filtro:

  • El query utiliza un campo inmutable como clave de búsqueda del query. Por ejemplo, buscar en el campo _id o utilizar $natural.

  • Ninguna actualización concurrente modifica la clave de búsqueda del query.

  • La clave de búsqueda tiene un índice único y el query utiliza ese índice.

Si se cumple alguno de los criterios anteriores, el query lee desde un snapshot coherente para devolver el único documento coincidente.

Siempre use maxTimeMS con un nivel de consistencia de lectura linealizable si la mayoría de los nodos que contienen datos no están disponibles. maxTimeMS garantiza que la operación devuelve un error si el nivel de consistencia de lectura no puede cumplirse, en lugar de bloquearse indefinidamente.

Para obtener más información, consulte la página de referencia "linearizable".

Un query con el nivel de consistencia de lectura "snapshot" devuelve datos comprometidos por mayoría tal como aparecen en las particiones desde un único punto específico en el tiempo en el pasado reciente. El nivel de consistencia de lectura "snapshot" proporciona sus garantías solo si la transacción obtiene su confirmación con el nivel de confirmación de escritura "majority".

If a transaction is not part of a causally consistent session, upon transaction commit with write concern "majority", the transaction operations are guaranteed to have read from a snapshot of majority-committed data.
If a transaction is part of a causally consistent session, upon transaction commit with write concern "majority", the transaction operations are guaranteed to have read from a snapshot of majority-committed data that provides causal consistency with the operation immediately preceding the transaction start.

Disponibilidad: El nivel de consistencia de lectura "snapshot" está disponible para

  • Todas las operaciones de lectura dentro de transacciones de múltiples documentos, con el nivel de consistencia de lectura configurado a nivel de transacción.

  • Los siguientes métodos, además de las transacciones multi-documento:

    Todas las demás operaciones de lectura prohíben "snapshot".

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 cada nivel de consistencia de lectura, consulta:

Para operaciones que no están en transacciones multi-documento, puedes especificar un nivel readConcern como una opción para comandos y métodos que admitan el nivel de consistencia de lectura:

readConcern: { level: <level> }

Para especificar el nivel de consistencia de lectura para mongosh método db.collection.find(), utilice el método cursor.readConcern():

db.collection.find().readConcern(<level>)

Para transacciones multidocumento, ajusta el nivel de consistencia de lectura a nivel de transacción, no a nivel de cada operación individual. Las operaciones de transacción utilizan el nivel de consistencia de lectura de nivel de transacción. Los niveles de consistencia de lectura establecidos a nivel de colección y base de datos son ignorados dentro de la transacción. Si defines explícitamente el nivel de consistencia de lectura de la transacción, también se ignorará el nivel de consistencia de lectura del cliente.

Importante

No asignes explícitamente el nivel de consistencia de lectura para operaciones individuales. Para establecer el nivel de consistencia de lectura para las transacciones, consulta Nivel de consistencia de lectura, nivel de confirmación de escritura (write concern) y preferencia de lectura.

Puedes establecer el nivel de consistencia de lectura al inicio de la transacción:

  • Las transacciones multi-documento admiten los siguientes niveles de consistencia de lectura:

  • Los comandos de escritura que forman parte de una Transacción multi-documento pueden admitir el nivel de consistencia de lectura a nivel de transacción.

  • Puede crear colecciones e índices dentro de una transacción. Si crea una colección o un índice explícitamente, la transacción debe utilizar el nivel de consistencia de lectura "local". Si crea una colección implícitamente, puede utilizar cualquiera de los niveles de consistencia de lectura disponibles para las transacciones.

Si no se especifica al inicio de la transacción, las transacciones utilizan el nivel de consistencia de lectura a nivel de sesión o, si este no está configurado, el nivel de consistencia de lectura a nivel de cliente.

Para obtener más información, consulta Transacción y nivel de consistencia de lectura.

Para las operaciones en una sesión causalmente coherente, están disponibles los niveles "local", "majority" y "snapshot". Para garantizar la consistencia causal, use "majority". Para obtener más información, consulte coherencia causal.

Las siguientes operaciones admiten nivel de consistencia de lectura:

Importante

Para establecer el nivel de consistencia de lectura para las operación de una transacción, el nivel de consistencia de lectura se debe establecer a nivel de transacción, no a nivel de la operación individual. No establezcas explícitamente el nivel de consistencia de lectura para la operación individual en una transacción. Para obtener más información, consulta Transacciones y nivel de consistencia de lectura.

[1] No puede utilizar la etapa $out o la etapa $merge junto con el nivel de consistencia de lectura "linearizable". Es decir, si especifica el nivel de consistencia de lectura "linearizable" para db.collection.aggregate(), no puede incluir ninguna de las dos etapas en el pipeline.
[2] El nivel de consistencia de lectura "snapshot" está disponible solo para ciertas operaciones de lectura y para transacciones multi-documento. En una transacción, no puede utilizar el comando distinct ni sus asistentes en una colección fragmentada.

Las siguientes operaciones de guardar también pueden aceptar un nivel de consistencia de lectura si forman parte de una transacción multi-documento:

Importante

Para establecer el nivel de consistencia de lectura para las operación de una transacción, el nivel de consistencia de lectura se debe establecer a nivel de transacción, no a nivel de la operación individual.

[3](1, 2) El nivel de consistencia de lectura "snapshot" está disponible solo para ciertas operaciones de lectura y transacciones multi-documento. Para transacciones, configure el nivel de consistencia de lectura en el nivel de transacción. Las operaciones de transacción que admiten "snapshot" corresponden a las operaciones CRUD disponibles en las transacciones. Para obtener más información, consulte Transacciones y nivel de consistencia de lectura.

La base de datos local no admite nivel de consistencia de lectura. MongoDB ignora silenciosamente cualquier nivel de consistencia de lectura configurado para operaciones en colecciones de la base de datos local.

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

Combinado con "majority" nivel de confirmación de escritura (write concern), "linearizable" nivel de consistencia de lectura permite que múltiples hilos realicen lecturas y escrituras en un solo documento como si un solo hilo realice estas operaciones en tiempo real. El cronograma correspondiente para estas lecturas y escrituras se considera linealizable.

A diferencia de "majority", el nivel de consistencia de lectura de "linearizable" confirma con los miembros secundarios que la operación de lectura se realiza desde un primario capaz de confirmar escrituras con un { w: "majority" } nivel de confirmación de escritura (write concern). [4] Las lecturas con nivel de consistencia de lectura linealizable pueden ser significativamente más lentas que las lecturas con "majority" o "local" niveles de consistencia de lectura.

Siempre use maxTimeMS con un nivel de consistencia de lectura linealizable si la mayoría de los nodos que contienen datos no están disponibles. maxTimeMS garantiza que la operación devuelve un error si el nivel de consistencia de lectura no puede cumplirse, en lugar de bloquearse indefinidamente.

Por ejemplo:

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)
db.runCommand( {
find: "restaurants",
filter: { _id: 5 },
readConcern: { level: "linearizable" },
maxTimeMS: 10000
} )
[4] 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.

MongoDB soporta sesiones con causalidad coherente. Para las operaciones de lectura en sesiones causalmente consistentes, los controladores establecen automáticamente la opción de nivel de consistencia de lectura afterClusterTime.

Importante

No establecer manualmente afterClusterTime para una operación de lectura. Los drivers de MongoDB establecen este valor de forma automática para las operaciones en sesiones causalmente consistentes. Sin embargo, puedes avanzar el operation time y el tiempo de clúster para la sesión, como para ser coherentes con las operaciones de otra sesión de cliente. Para ver un ejemplo, consulta Ejemplos.

Nota

No puede especificar atClusterTime junto con afterClusterTime. Para usar atClusterTime con el nivel de consistencia de lectura "snapshot", deshabilite las sesiones causalmente consistentes.

Para satisfacer una solicitud de lectura con un valor de afterClusterTime de T, se debe realizar la solicitud después de que su oplog llegue a la hora T. mongod. Si su oplog no ha alcanzado el tiempo T, el mongod espera para atender la solicitud.

Las operaciones de lectura con un afterClusterTime especificado devuelven datos que cumplen tanto con el requerimiento de nivel de consistencia de lectura como con el requerimiento de afterClusterTime especificado.

Para las operaciones de lectura no asociadas a sesiones causalmente coherentes, no se establece afterClusterTime.

MongoDB rastrea el nivel de consistencia de lectura provenance, el cual indica la fuente de un nivel de consistencia de lectura. El valor provenance aparece en las getLastError métricas, en los objetos de error de nivel de consistencia de lectura y en los logs de MongoDB.

La siguiente tabla muestra los posibles valores de nivel de consistencia de lectura provenance y su significado:

Origen
Descripción

clientSupplied

El nivel de consistencia de lectura se especificó en la aplicación.

customDefault

El nivel de consistencia de lectura se originó a partir de un valor por defecto personalizado. Consulta setDefaultRWConcern.

implicitDefault

El nivel de consistencia de lectura se originó desde el servidor en ausencia de todas las demás especificaciones de nivel de consistencia de lectura.

Volver

Objetos GeoJSON

En esta página