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
mongosnã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.
Disponibilidade
A preocupação de leitura "available" não está disponível para uso com sessões e transações causalmente consistentes.
Exemplo
Considere a seguinte linha do tempo de uma operação de gravação Escrever 0 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 0 foram replicadas com sucesso para todos os membros.
Escrever prev é a escrita anterior antes de Escrever 0.
Nenhuma outra gravação ocorreu após Write 0.
Hora | Evento | Escrita mais recente | Mais recente w: escrita da "maioria" |
|---|---|---|---|
t 0 | Primário aplica Write 0 | Primary: Gravar 0 | Primary: Gravar anterior |
t 1 | O secundário 1 aplica a gravação 0 | Primary: escrever 0 | Primary: Gravar anterior |
t 2 | O secundário 2 aplica a escrita 0 | Primário: Escrever 0 | Primary: Gravar anterior |
t 3 | O Primário está ciente do sucesso da replicação para o Secundário 1 e envia uma confirmação ao cliente | Primário: Escrever 0 | Primary: Gravar 0 |
t 4 | O primary está ciente da replicação bem-sucedida para o secundário 2 | Primário: Escrever 0 | Primary: Gravar 0 |
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 | Primário: Escrever 0 | Primary: escrever 0 |
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 | Primário: Escrever 0 | Primário: Escrever 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 |