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 queries com a read concern "available" não exigem uma verificação para garantir que o shard correto recebeu a query.

  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 estiver passando por uma migração de chunk, as queries com "available" poderão retornar documentos órfãos.

  Aviso

  mongos não garante que as queries com read concern "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 standalone ou uma implantação de conjunto de réplicas), "local" e "available" preocupações de 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.

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: escrever 0 secundário 1: Escrever anterior secundário 2: Escrever anterior	Primary: escrever anterior secundário 1: Escrever anterior secundário 2: Escrever anterior
t 1	O secundário 1 aplica a gravação 0	Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escrever anterior	Primary: escrever anterior secundário 1: Escrever anterior secundário 2: Escrever anterior
t 2	O secundário 2 aplica a escrita 0	Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0	Primary: escrever anterior secundário 1: Escrever anterior secundário 2: Escrever 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	Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0	Primary: escrever 0 secundário 1: Escrever anterior secundário 2: Escrever anterior
t 4	O primary está ciente da replicação bem-sucedida para o secundário 2	Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0	Primary: escrever 0 secundário 1: Escrever anterior secundário 2: Escrever anterior
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: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0	Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escrever anterior
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: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0	Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0

Depois, as tabelas a seguir resumem o estado dos dados que uma operação de leitura com "available" read concern 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