readConcern "available"

Una consulta con nivel de consistencia de lectura "available" devuelve datos de la instancia sin garantías de que los datos se hayan escrito en la mayoría de los miembros del set de réplicas (es decir, es posible que se reviertan).

• Para un clúster particionado, "available" el nivel de consistencia de lectura proporciona una mayor tolerancia a las particiones.

  Las "available" con el nivel de consistencia de lectura no requieren una verificación para garantizar que la partición correcta haya recibido la query.

  En caso de particiones de red, estas consultas se dirigen a la partición considerada apropiada antes de que ocurriera la partición de red. No esperan garantías de coherencia de servidores que pueden no estar disponibles. Si la partición estaba en proceso de migración de fragmento, las queries con "available" pueden devolver documento huérfano.

  Advertencia

  mongos no garantiza que las consultas con nivel de consistencia de lectura "available" se dirijan a los shards correctos. La partición que recibe la query devuelve datos, pero es posible que esta partición no sea el propietario autorizado de los datos solicitados.

  Esto puede causar que las consultas devuelvan resultados incorrectos o inesperados.

• Para las colecciones no particionadas (incluidas las colecciones en una implementación autónoma o una implementación de conjunto de réplicas), "local" y "available" los niveles de consistencia de lectura se comportan de manera idéntica.

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.

Ejemplo

Considera la siguiente cronología de una operación de escritura. Escribe ₀ en un set de réplicas de tres nodos:

Nota

Para simplificar, el ejemplo asume:

• Todas las operaciones de escritura anteriores a la escritura ₀ se han replicado correctamente en todos los nodos.

• Write _prev es la guardar anterior a Write ₀.

• No se han producido otras escrituras después de la escritura ₀.

Tiempo	Evento	Último guardar	Más reciente w: "mayoría" guardar
t 0	El primario aplica guardar 0	Primary: Write 0 Secondary 1: Write prev Secondary 2: Write prev	Primary: Write prev Secondary 1: Write prev Secondary 2: Write prev
t 1	Secundario 1 aplica guardar 0	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write prev	Primary: Write prev Secondary 1: Write prev Secondary 2: Write prev
t 2	Secundaria 2 aplica guardar 0	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0	Primary: Write prev Secondary 1: Write prev Secondary 2: Write prev
t 3	Principal está al tanto de la replicación exitosa a Secundario 1 y envía acuse de recibo al cliente	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0	Primary: Write 0 Secondary 1: Write prev Secondary 2: Write prev
t 4	El primario está al tanto de la replicación exitosa del secundario 2	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0	Primary: Write 0 Secondary 1: Write prev Secondary 2: Write prev
t 5	El Secundario 1 recibe la notificación (a través del mecanismo regular de replicación) para actualizar su snapshot de su última w: guardar de "mayoría"	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write prev
t 6	El secundario 2 recibe un aviso (a través del mecanismo de replicación regular) para actualizar su snapshot de su escritura más reciente de "mayoría".	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0

Luego, la siguiente tabla resume el estado de los datos que una operación de lectura con "available" nivel de consistencia de lectura vería en el momento T.

Leer destino	Tiempo T	Estado de los datos
Primario	Después de t 0	Los datos reflejan Guardar 0.
Secundaria 1	Antes de t 1	Los datos reflejan guardar prev
Secundaria 1	Después de t 1	Los datos reflejan guardar 0
Secundario 2	Antes de t 2	Los datos reflejan guardar prev
Secundario 2	Después de t 2	Los datos reflejan guardar 0