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 su conjunto de réplicas fallan y se reinician después de la operación de lectura, los documentos devueltos por la operación de lectura son duraderos si
writeConcernMajorityJournalDefault se establece en el estado 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.
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 consistentes
La lectura de la preocupación no está disponible para su uso con sesiones causalmente consistentes."linearizable"
Restricción de agregación
No se pueden usar las etapas$outni$mergejunto con la tarea de lectura"linearizable". Es decir, si se especifica la tarea de lectura"linearizable"paradb.collection.aggregate(), no se pueden incluir ninguna de las etapas en la canalización.
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 "majority" { w: "majority" } de, la preocupación de lectura confirma con miembros secundarios que la operación de lectura"linearizable" está leyendo desde un miembro principal que es capaz de confirmar escrituras con preocupación de escritura.1 [] Como tal, las lecturas con preocupación de lectura linealizable pueden ser significativamente más lentas que las lecturas con preocupaciones de lectura "majority" "local" o.
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. |