readConcern

Esta versión de la documentación está archivada y ya no recibe soporte. Para actualizar su implementación 6.0, consulte Procedimientos de actualización de MongoDB.7.0

El readConcern La opción le permite controlar las propiedades de consistencia y aislamiento de los datos leídos desde conjuntosde réplicas y clústeres fragmentados.

Mediante el uso efectivo de niveles de confirmación de escritura y niveles de consistencia de lectura, puedes ajustar el nivel de las garantías de coherencia y disponibilidad según convenga, como esperar garantías de coherencia más sólidas o flexibilizar los requisitos de coherencia para proporcionar mayor disponibilidad.

Los Sets de réplicas y los clústeres particionados son compatibles con la configuración de un nivel de consistencia de lectura global por defecto. Las operaciones que no especifican un nivel de consistencia de lectura explícito heredan la configuración global por defecto del nivel de consistencia de lectura. Consulta setDefaultRWConcern para obtener más información.

Niveles de consistencia de lectura

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

`level`	Descripción
`"local"`	El query devuelve datos de la instancia sin garantías de que los datos se hayan escrito en la mayoría de los nodos del set de réplicas (es decir, pueden revertirse). Por defecto para las lecturas en el primario y los secundarios. Disponibilidad: el nivel de consistencia de lectura `"local"` está disponible para su uso con o sin sesiones y transacciones causalmente coherentes. Para obtener más información, consulte la página de referencia `"local"`.
`"available"`	El query devuelve datos de la instancia sin garantías de que los datos se hayan escrito en la mayoría de los nodos del set de réplicas (es decir, pueden revertirse). Disponibilidad: Leer la preocupación `"available"` es no disponible para su uso con sesiones y transacciones causalmente consistentes. 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"`.
`"majority"`	La query devuelve los datos que han sido reconocidos por la mayoría de los nodos del set de réplicas. Los documentos devueltos por la operación de lectura son durables, incluso en el evento de fallo. Para cumplir con el nivel de consistencia de lectura "mayoría", el nodo del set de réplicas devuelve datos desde su vista en memoria de los datos en el punto de confirmación de la mayoría. Por lo tanto, el nivel de consistencia de lectura `"majority"` es parecido en costo de rendimiento a otros niveles de consistencia de lectura. Disponibilidad: El nivel de consistencia de lectura `"majority"` está disponible para su uso con o sin sesiones y transacciones causalmente coherentes. Requisitos: para utilizar el nivel de consistencia de lectura de `"majority"`, los sets de réplicas deben utilizar el motor de almacenamiento WiredTiger. Para operaciones en transacciones multi-documento, el nivel de consistencia de lectura `"majority"` proporciona sus garantías solo si la transacción se confirma con nivel de confirmación de escritura "mayoría". De lo contrario, el nivel de consistencia de lectura `"majority"` no proporciona garantías sobre los datos leídos en las transacciones. Para obtener más información, consulte la página de referencia `"majority"`.
`"linearizable"`	La query devuelve datos que reflejan todas las escrituras exitosas reconocidas por la mayoría que se completaron antes del inicio de la operación de lectura. La query puede esperar a que las operaciones de guardar que se ejecutan simultáneamente se propaguen a la mayoría de los miembros del set de réplicas antes de devolver los resultados. Si la mayoría de los nodos del set de réplicas se bloquean y se reinician tras la operación de lectura, los documentos devueltos por la operación de lectura son durables si `writeConcernMajorityJournalDefault` está configurado en el estado 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. Puedes especificar el nivel de consistencia de lectura linealizable para leer las operaciones solo 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 el nivel de consistencia de lectura linealizable en caso de que la mayoría de los miembros con datos no estén disponibles. `maxTimeMS` garantiza que la operación no se bloquee indefinidamente y, en su lugar, garantiza que la operación devuelva un error si no se puede cumplir el nivel de consistencia de lectura. Para obtener más información, consulte la página de referencia `"linearizable"`.
`"snapshot"`	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 contenidas en las transacciones multi-documento con el nivel de consistencia de lectura establecido a nivel de transacción. Los siguientes métodos, además de las transacciones multi-documento: `find` `aggregate` `distinct` (en colecciones no fragmentadas) 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:

`readConcern` Soporte

Opción de nivel de consistencia de lectura

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 el método mongosh db.collection.find(), utiliza el método cursor.readConcern():

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

Transacciones y niveles de consistencia de lectura disponibles

Para transacciones multi-documento, estableces el nivel de consistencia de lectura al nivel de la transacción, no a nivel de la operación individual. Las operaciones de la transacción utilizarán el nivel de consistencia de lectura a nivel de transacción. El nivel de consistencia de lectura establecido a nivel de colección y base de datos se ignora dentro de la transacción. Si se especifica explícitamente el nivel de consistencia de lectura a nivel de transacción, se ignora el nivel de consistencia de lectura a nivel de cliente dentro de la transacción.

Importante

No establezca explícitamente el nivel de consistencia de lectura para las operaciones individuales. Para establecer el nivel de consistencia de lectura para las transacciones, consulte Nivel de consistencia de lectura/Nivel de confirmación de escritura/Preferencia de lectura.

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

Para la transacción multi-documento, los siguientes niveles de consistencia de lectura están disponibles:
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.

Sesiones causalmente coherentes y niveles de consistencia de lectura disponibles

Para las operaciones en una sesión causalmente coherente, están disponibles los niveles "local", "majority" y "snapshot". Sin embargo, para garantizar la coherencia causal, debes usar "majority". Para obtener más información, consulta Coherencia causal.

Operaciones que admiten nivel de consistencia de lectura

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.

Comando/Método	`"local"`	`"available"`	`"majority"`	`"snapshot"` [3]	`"linearizable"`
`count`	✓	✓	✓		✓
`distinct`	✓	✓	✓	✓ [2]	✓
`find`	✓	✓	✓	✓	✓
`db.collection.find()` vía `cursor.readConcern()`	✓	✓	✓	✓	✓
`getMore`	✓				✓
`aggregate` `db.collection.aggregate()`	✓	✓	✓	✓	✓ [3]
`Session.startTransaction()`	✓		✓	✓

[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

Comando	`"local"`	`"snapshot"` [3]
`delete` `db.collection.deleteOne()` `db.collection.deleteMany()` `db.collection.remove()`	✓	✓
`findAndModify` `db.collection.findAndModify()` `db.collection.findOneAndDelete()` `db.collection.findOneAndReplace()` `db.collection.findOneAndUpdate()`	✓	✓
`insert` `db.collection.insertOne()` `db.collection.insertMany()`	✓	✓
`update` `db.collection.updateOne()` `db.collection.updateMany()` `db.collection.replaceOne()`	✓	✓
`create` `db.createCollection()` (Requires FCV 6.0 or greater)	✓
`createIndexes` `db.collection.createIndex()` `db.collection.createIndexes()` (Requires FCV 6.0 or greater)	✓

[3] (1, 2) El nivel de consistencia de lectura "snapshot" está disponible solo para ciertas operaciones de lectura y transacciones multi-documento. Para las transacciones, se establece el nivel de consistencia de lectura a 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, se debe consultar Transacciones y nivel de consistencia de lectura.

Preocupación de lectura no admitida en la `local` base de datos

La base de datos local no admite nivel de consistencia de lectura. MongoDB ignora silenciosamente cualquier nivel de consistencia de lectura configurado para una operación en una colección de la base de datos local.

Considerations

Lee tus propios guardados

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

Orden en tiempo real

Combinado con el nivel de confirmación de escritura "majority", el nivel de consistencia de lectura"linearizable" permite que múltiples hilos realicen lecturas y escrituras en un solo documento como si un solo hilo realizara estas operaciones en tiempo real; es decir, el cronograma correspondiente para estas lecturas y escrituras se considera linealizable.

Comparaciones de rendimiento

A diferencia del nivel "majority", el nivel de consistencia de lectura "linearizable" confirma con los miembros secundarios que la operación de lectura está leyendo desde un primario que es capaz de confirmar las escrituras con el nivel de confirmación de escritura { w: "majority" }. [4] Como tal, las lecturas con el nivel de consistencia de lectura linealizable pueden ser significativamente más lentas que las lecturas con los niveles de consistencia de lectura "majority" o "local".

Siempre use maxTimeMS con el nivel de consistencia de lectura linealizable en caso de que la mayoría de los miembros con datos no estén disponibles. maxTimeMS garantiza que la operación no se bloquee indefinidamente y, en su lugar, garantiza que la operación devuelva un error si no se puede cumplir el nivel de consistencia de lectura.

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.

Operaciones de lectura y `afterClusterTime`

MongoDB incluye soporte para sesiones coherentes con la causalidad. Para las operaciones de lectura asociadas con sesiones causalmente coherentes, MongoDB proporciona el soporte para que la opción de nivel de consistencia de lectura afterClusterTime sea establecida automáticamente por los controladores para las operaciones asociadas con sesiones causalmente coherentes.

Importante

No establezcas afterClusterTime manualmente para una operación de lectura. Los controladores de MongoDB establecen este valor automáticamente para las operaciones asociadas con sesiones causalmente coherentes. Sin embargo, puedes adelantar el tiempo de operación y el tiempo del clúster para la sesión, de manera que sea coherente con las operaciones de otra sesión de cliente. Para ver un ejemplo, consulta Ejemplos.

Nota

No es posible especificar atClusterTime en conjunto con afterClusterTime. Para usar atClusterTime con el nivel de consistencia de lectura "snapshot" tienes que desactivar sesiones causalmente coherentes.

Para procesar una solicitud de lectura con un valor afterClusterTime de T, el mongod debe ejecutar la solicitud después de que su oplog cumpla el tiempo T. Si su oplog no ha cumplido el tiempo T, el mongod debe esperar para atender la solicitud.

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

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

Procedencia del nivel de consistencia de lectura

MongoDB rastrea el nivel de consistencia de lectura provenance, que indica la fuente de un nivel de consistencia de lectura concreto. Puede que vea provenance en las métricas de getLastError, en los objetos de error de nivel de consistencia de lectura, y en los registros 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

"local"

Niveles de consistencia de lectura

readConcern Soporte

Opción de nivel de consistencia de lectura

Transacciones y niveles de consistencia de lectura disponibles

Importante

Sesiones causalmente coherentes y niveles de consistencia de lectura disponibles

Operaciones que admiten nivel de consistencia de lectura

Importante

Importante

Preocupación de lectura no admitida en la local base de datos

Considerations

Lee tus propios guardados

Orden en tiempo real

Comparaciones de rendimiento

Operaciones de lectura y afterClusterTime

Importante

Nota

Procedencia del nivel de consistencia de lectura

`readConcern` Soporte

Preocupación de lectura no admitida en la `local` base de datos

Operaciones de lectura y `afterClusterTime`