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).
For a sharded cluster,
"available"read concern provides greater tolerance for partitions.Queries with the
"available"read concern don't require a check to ensure that the correct shard received the query.In the event of network partitions, these queries route to the shard considered appropriate before the network partition occurred. They do not wait for consistency guarantees from servers that may be unavailable. If the shard was undergoing chunk migration, queries with
"available"can return orphaned documents.Aviso
mongosdoes not guarantee that queries with read concern"available"route to the correct shards. The shard that receives the query returns data, but this shard may not be the authoritative owner of the requested data.Isso pode fazer com que as queries retornem resultados incorretos ou inesperados.
For unsharded collections (including collections in a standalone deployment or a replica set deployment),
"local"and"available"read concerns behave identically.
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
Read concern "available" is unavailable for use with causally consistent sessions and transactions.
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 | primário: gravar 0 | Primário: gravar prev |
t 1 | O secundário 1 aplica a gravação 0 | Primário: gravar 0 | Primário: gravar prev |
t 2 | O secundário 2 aplica a escrita 0 | primário: gravar 0 | Primário: gravar 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 | primário: gravar 0 | primário: gravar 0 |
t 4 | O primary está ciente da replicação bem-sucedida para o secundário 2 | primário: gravar 0 | primário: 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: gravar 0 | Primário: gravar 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: gravar 0 | primário: gravar 0 |
Then, the following tables summarizes the state of the data that a read operation with "available" read concern would see at time 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 |