readConcern

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

Mediante el uso eficaz de las garantías de escritura y lectura, puede ajustar el nivel de consistencia y disponibilidad. Por ejemplo, puede esperar a que existan garantías de consistencia más estrictas o flexibilizar los requisitos de consistencia para lograr una mayor disponibilidad.

Los conjuntos de réplicas y los clústeres fragmentados admiten una política de lectura global predeterminada. Las operaciones sin una política de lectura explícita heredan la política global predeterminada. Consulte para obtener más setDefaultRWConcern información.

Niveles de consistencia de lectura

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

`level`	Descripción
`"local"`	La consulta devuelve datos de la instancia sin garantía de que estos se hayan escrito en la mayoría de los miembros del conjunto de réplicas. Los datos podrían revertirse. Por defecto para las lecturas en el primario y los secundarios. Disponibilidad: La preocupación de lectura está disponible con o sin sesiones y transacciones causalmente consistentes.`"local"` Para obtener más información, consulte la página de referencia `"local"`.
`"available"`	La consulta devuelve datos de la instancia sin garantía de que estos se hayan escrito en la mayoría de los miembros del conjunto de réplicas. Los datos podrían revertirse. 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"`.
`"majority"`	La consulta devuelve los datos confirmados por la mayoría de los miembros del conjunto de réplicas. Los documentos devueltos son persistentes, incluso si se produce un fallo. Para cumplir con la preocupación de `"majority"` lectura, el miembro del conjunto de réplicas devuelve datos de su vista en memoria en el punto de confirmación mayoritaria. La preocupación de lectura tiene un rendimiento comparable al de otras preocupaciones de `"majority"` lectura. Disponibilidad: La preocupación de lectura está disponible con o sin sesiones y transacciones causalmente consistentes.`"majority"` Requisitos: Los conjuntos de réplicas deben utilizar el motor de almacenamiento WiredTiger. Para transacciones de múltiples documentos, la garantía de lectura `"majority"` solo se aplica si la transacción se confirma con una "mayoría" de garantía de escritura. De lo contrario, `"majority"` no ofrece ninguna garantía sobre los datos leídos en las transacciones. Para obtener más información, consulte la página de referencia `"majority"`.
`"linearizable"`	La consulta devuelve datos que reflejan todas las escrituras exitosas confirmadas por la mayoría que se completaron antes del inicio de la operación de lectura. La consulta puede esperar a que las escrituras concurrentes se propaguen a la mayoría de los miembros del conjunto de réplicas antes de devolver los resultados. Si la mayoría de los miembros de su conjunto de réplicas fallan y se reinician después de la operación de lectura, los documentos devueltos son duraderos si se establece en el valor `writeConcernMajorityJournalDefault` predeterminado `true` de. 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 la preocupación de lectura linealizable para las operaciones de lectura en `primary` el. 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. Utilice siempre `maxTimeMS` con una condición de lectura linealizable si la mayoría de los miembros que contienen datos no están disponibles. `maxTimeMS` garantiza que la operación devuelva un error si no se puede cumplir la condición de lectura, en lugar de bloquearse indefinidamente. 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: Lea `"snapshot"` la preocupación está disponible para Todas las operaciones de lectura dentro de transacciones de múltiples documentos, con la prioridad de lectura establecida a nivel de transacción. Los siguientes métodos, además de las transacciones multi-documento: `find` `aggregate` `distinct` Solo 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 mongosh método db.collection.find(), utilice el método cursor.readConcern():

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

Transacciones y niveles de consistencia de lectura disponibles

Para transacciones con varios documentos, configure la restricción de lectura a nivel de transacción, no a nivel de operación individual. Las operaciones de transacción utilizan la restricción de lectura a nivel de transacción. Las restricciones de lectura configuradas a nivel de colección y base de datos se ignoran dentro de la transacción. Si configura explícitamente la restricción de lectura a nivel de transacción, la restricción de lectura a nivel de cliente también se ignora.

Importante

No configure explícitamente la prioridad de lectura para operaciones individuales. Para configurar la prioridad de lectura para transacciones, consulte Prioridad de lectura/Prioridad de escritura/Preferencia de lectura.

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

Las transacciones multidocumento admiten los siguientes niveles de preocupación 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.

Sesiones causalmente coherentes y niveles de consistencia de lectura disponibles

Para operaciones en una sesión causalmente consistente, están disponibles los niveles"local", "majority"y"snapshot". Para garantizar la consistencia causal, utilice"majority". Para más detalles, consulte Consistencia 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 ) La preocupación de lectura"snapshot"solo está disponible para ciertas operaciones de lectura y transacciones de varios documentos. Para las transacciones, configure la preocupación 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, consulte Transacciones y preocupación de lectura.

Nivel de consistencia de lectura no es compatible con la base de datos `local`

La base de datos local no admite restricciones de lectura. MongoDB ignora silenciosamente cualquier restricción de lectura configurada para las operaciones en colecciones 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

En combinación con la funcionalidad "majority" de escritura, la funcionalidad de lectura permite que varios subprocesos realicen lecturas y escrituras en un mismo documento como si un solo subproceso realizara estas operaciones en tiempo real. La programación correspondiente para estas lecturas y escrituras se considera linealizable. "linearizable"

Comparaciones de rendimiento

A diferencia "majority" { w: "majority" } de, la preocupación de lectura confirma con los miembros secundarios que la"linearizable" operación de lectura4 lee desde un primario capaz de confirmar escrituras con preocupación de escritura. [] Las lecturas con preocupación de lectura linealizable pueden ser significativamente más lentas que las lecturas con "majority" "local" preocupaciones de lectura o.

Utilice siempre maxTimeMS con una condición de lectura linealizable si la mayoría de los miembros que contienen datos no están disponibles. maxTimeMS garantiza que la operación devuelva un error si no se puede cumplir la condición de lectura, 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.

Operaciones de lectura y `afterClusterTime`

MongoDB admite sesiones causalmente consistentes. Para las operaciones de lectura en sesiones causalmente consistentes, los controladores establecen automáticamente la afterClusterTime opción de preocupación de lectura.

Importante

No establezca manualmente afterClusterTime para una operación de lectura. Los controladores de MongoDB establecen este valor automáticamente para las operaciones en sesiones causalmente consistentes. Sin embargo, puede adelantar la hora de la operación y la hora del clúster para la sesión, por ejemplo, para que sean consistentes con las operaciones de otra sesión de cliente. Para ver un ejemplo, consulte la sección Ejemplos.

Nota

No se puede especificar atClusterTime junto afterClusterTime con. Para usar atClusterTime con la preocupación "snapshot" de lectura, desactive las sesiones causalmente consistentes.

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

Las operaciones afterClusterTime afterClusterTime de lectura con un especificado devuelven datos que cumplen tanto el requisito de nivel de preocupación de lectura como el requisito especificado.

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

Procedencia del nivel de consistencia de lectura

MongoDB realiza provenance un seguimiento de la preocupación de lectura, que indica el origen de dicha preocupación. El provenance valor aparece en las getLastError métricas, los objetos de error de preocupación de lectura y 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

Nivel de consistencia de lectura no es compatible con la base de datos local

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

Nivel de consistencia de lectura no es compatible con la base de datos `local`

Operaciones de lectura y `afterClusterTime`