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 fornece maior tolerância para
"available"partições.As queries com a preocupação de leitura não exigem uma verificação para garantir que o shard correto tenha recebido a
"available"query.No evento 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 estiver passando por uma migração de chunk, as queries com poderão
"available"retornar documentos órfãos.Aviso
mongosnão garante que as queries com preocupação de leitura"available"sejam roteadas para os shards corretos. O fragmento que recebe a query retorna dados, mas esse fragmento pode não ser o proprietário oficial dos dados solicitados.Isso pode fazer com que as queries retornem resultados incorretos ou inesperados.
Para collections não fragmentadas (incluindo collections em uma implantação autônomo ou uma implantação de conjunto de
"local"réplicas), e preocupações de"available"leitura 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 read concern "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 "available" preocupação de leitura veria no T momento.
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 |