Read concern "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" oferece maior tolerância às 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 evento de partição de rede, essas consultas são roteadas para o fragmento considerado apropriado antes que a partição de rede ocorra. Elas não esperam garantias de consistência de servidores que talvez não estejam disponíveis. Se o fragmento estava passando por migração de particionada, as consultas com "available" podem 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 primário 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	Tempo T	Estado dos dados
Principal	Depois de t 0	Os dados refletem a gravação 0.
secundário 1	Antes de t 1	Os dados refletem a gravação anterior
secundário 1	Depois de t 1	Os dados refletem a gravação 0
secundário 2	Antes de t 2	Os dados refletem a gravação anterior
secundário 2	Depois de t 2	Os dados refletem a gravação 0