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 miembros de tu set de réplicas se bloquean y reinician después de la operación de lectura, los documentos devueltos por la operación de lectura son duraderos 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.
Puedes especificar el nivel de consistencia de lectura linealizable para leer las operaciones solo en el primary.
Tip
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.
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
_ido 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.
Sesiones causalmente coherentes
El nivel de consistencia de lectura "linearizable" no está disponible para su uso en sesiones causalmente coherentes.
Restricción de agregación
No puede utilizar la etapa $out ni la $merge junto con el nivel de consistencia de lectura "linearizable". Es decir, si se especifica "linearizable" el nivel de consistencia de lectura para db.collection.aggregate(), no se pueden incluir etapas en la pipeline.
Orden en tiempo real
Combinado con la preocupación "majority" "linearizable" de escritura, la preocupación de lectura permite que varios subprocesos realicen lecturas y escrituras en un solo documento como si un solo subproceso realizara estas operaciones en tiempo real; es decir, la programación correspondiente para estas lecturas y escrituras se considera linealizable.
Lee tus propios guardados
Se pueden utilizar sesiones con coherencia causal para leer tus propias escrituras, si las escrituras solicitan reconocimiento.
Comparaciones de rendimiento
A diferencia de "majority", "linearizable", el nivel de consistencia de lectura se confirma con los nodos secundarios que la operación de lectura se está realizando desde un nodo primario que es capaz de confirmar escrituras con { w: "majority" } nivel de confirmación de escritura (write concern). [1] Como tal, las lecturas con nivel de consistencia de lectura linealizable pueden ser significativamente más lentas que las lecturas con "majority" o con nivel de consistencia de lectura "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 } )
| [1] | 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. |