Preocupação de leitura "available"

Uma query com read concern "available" retorna dados da instância sem nenhuma garantia de que os dados foram escritos na maioria dos membros do conjunto de réplicas (ou seja, podem ser revertidos).

• Para um cluster fragmentado, a preocupação de leitura "available" fornece maior tolerância para partições.

  As consultas com a preocupação de leitura "available" não exigem uma verificação para garantir que o fragmento correto tenha recebido a consulta.

  No caso de partições de rede, essas queries são roteadas para o shard considerado apropriado antes da ocorrência da partição de rede. Eles não esperam por garantias de consistência de servidores que podem estar indisponíveis. Se o shard estivesse passando por uma migração de chunk, as queries com "available" poderão retornar documentos órfãos.

  Aviso

  mongos não garante que queries com preocupação de leitura "available" sejam roteadas para os fragmentos corretos. O fragmento que recebe a query retorna dados, mas esse fragmento pode não ser o proprietário autorizado dos dados solicitados.

  Isso pode fazer com que as queries retornem resultados incorretos ou inesperados.

• Em coleções não fragmentadas (inclusive coleções em sistemas autônomos ou implantação do conjunto de réplicas), as preocupações de leitura "local" e "available" se comportam de forma idêntica.

Independentemente do nível de read concern, os dados mais recentes em um nó podem não refletir a versão mais recente dos dados no sistema.

Exemplo

Considere a seguinte linha do tempo de uma operação de gravação Escrever ₀ para um conjunto de réplicas de três membros:

Observação

Para simplificar, o exemplo pressupõe:

• Todas as gravações anteriores à gravação ₀ foram replicadas com sucesso para todos os membros.

• Escrever _prev é a escrita anterior antes de Escrever ₀.

• Nenhuma outra gravação ocorreu após Write ₀.

Hora	Evento	Escrita mais recente	Mais recente w: escrita da "maioria"
t 0	Primário aplica Write 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	O secundário 1 aplica a gravação 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	O secundário 2 aplica a escrita 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	O Primário está ciente do sucesso da replicação para o Secundário 1 e envia uma confirmação ao 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	O primary está ciente da replicação bem-sucedida para o secundário 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	O secundário 1 recebe um aviso (por meio de mecanismo de replicação regular) para atualizar o snapshot de sua gravação w: "maioria" mais recente	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write prev
t 6	O secundário 2 recebe um aviso (por meio do mecanismo de replicação regular) para atualizar seu snapshot do w mais recente: "majority" write	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0	Primary: Write 0 Secondary 1: Write 0 Secondary 2: Write 0

Depois, as tabelas a seguir resumem o estado dos dados que uma operação de leitura com a preocupação de leitura "available" veria no momento T.

Meta de leitura	Hora T	Estado dos dados
Principal	Após t 0	Os dados refletem a gravação 0.
Secundário 1	Antes de 1	Os dados refletem a gravação anterior
Secundário 1	Após t 1	Os dados refletem Gravação 0
Secundário 2	Antes de 2	Os dados refletem a gravação anterior
Secundário 2	Após t 2	Os dados refletem Gravação 0