Preocupação de leitura
A opção readConcern permite controlar as propriedades de consistência e isolamento dos dados lidos de conjuntos de réplicas e clusters fragmentados.
Por meio do uso efetivo de write concerns e read concerns, você pode ajustar o nível de garantias de consistência e disponibilidade conforme apropriado, como esperar por garantias de consistência mais fortes ou afrouxar os requisitos de consistência para fornecer maior disponibilidade.
Os conjuntos de réplicas e clusters fragmentados são compatíveis com a configuração de uma referência de leitura padrão global. As operações que não especificam uma referência de leitura explícita herdam as configurações globais padrão da referência de leitura. Consulte setDefaultRWConcern para obter mais informações.
Níveis de preocupação de leitura
Os seguintes níveis de read concern estão disponíveis:
level | Descrição |
|---|---|
A query 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). Padrão para leituras em relação ao primário e aos secundários. Disponibilidade: Read concern Para mais informações, consulte a página de referência do | |
A query 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). Disponibilidade: A read concern Para clusters fragmentados, um read concern Para mais informações, consulte a página de referência do | |
A query retorna os dados que foram confirmados por uma maioria dos membros do conjunto de réplicas. Os documentos retornados pela operação de leitura são duráveis, mesmo em caso de falha. Para executar a read concern "maioria", o membro do conjunto de réplicas retorna dados de sua exibição na memória dos dados no ponto de confirmação de maioria. Como tal, a read concern é comparável em custo de desempenho a outras read Disponibilidade: Read concern Requisitos: Para usar o nível de read concern de Para operações em multi-document transactions, a read concern Para mais informações, consulte a página de referência do | |
A query retorna dados que refletem todas as escritas bem-sucedidas confirmadas pela maioria que foram concluídas antes do início da operação de leitura. A query pode esperar que as escritas de execução simultânea se propaguem para a maioria dos membros do conjunto de réplicas antes de retornar os resultados. Se a maioria dos membros do seu conjunto de réplica falhar e reiniciar após a operação de leitura, os documentos retornados pela operação de leitura serão duráveis se o Com
Não é possível usar o stage Requisitos: As garantias de leitura linearizável só se aplicam se operações de leitura especificarem um filtro de queries que exclusivamente identifique um único documento. Além disso, se nenhum dos critérios a seguir for atendido, a preocupação de leitura linearizável poderá não ler de um snapshot consistente, fazendo com que um documento correspondente ao filtro não seja retornado:
Se algum dos critérios anteriores for atendido, a query lerá a partir de um snapshot consistente para retornar o único documento correspondente . Sempre use Para mais informações, consulte a página de referência do | |
Uma query com read concern If a transaction is not part of a causally consistent
session, upon transaction commit with write
concern "majority", the transaction operations
are guaranteed to have read from a snapshot of
majority-committed data.If a transaction is part of a causally consistent
session, upon transaction commit with write
concern "majority", the transaction operations
are guaranteed to have read from a snapshot of
majority-committed data that provides causal consistency with
the operation immediately preceding the transaction start.Disponibilidade: A read concern
|
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.
Para obter mais informações sobre cada nível de read concern, consulte:
readConcern Suporte
Opção de preocupação de leitura
Para operações que não estejam em transações de vários documentos, você pode especificar um readConcern nível read concern como uma opção para comandos e métodos que suportam a read concern:
readConcern: { level: <level> }
Para especificar o nível de preocupação de leitura para o método mongosh db.collection.find(), utilize o método cursor.readConcern():
db.collection.find().readConcern(<level>)
Transações e preocupações de leitura disponíveis
Para transações com vários documentos, você define a questão de leitura no nível da transação, não no nível de operação individual. As operações na transação usarão a read concern no nível da transação. Qualquer read concern definido no nível da coleção e do banco de dados é ignorado dentro da transação. Se o problema de leitura no nível da transação for explicitamente especificado, o problema de leitura no nível do cliente também será ignorado dentro da transação.
Importante
Não defina explicitamente a read concern para as operações individuais. Para definir a read concern para transações, consulte Read Concern/Write Concern/Read Preference.
Você pode definir o read concern no início da transação:
Para transações multidocumento, os seguintes níveis de read concern estão disponíveis:
Comandos de write que are part of uma multi-document transactions podem suportar a read concern de leitura no nível da transação.
Você pode criar coleções e índices dentro de uma transação. Se estiver criando explicitamente uma coleção ou um índice, a transação deverá usar a read concern
"local". Se você criar implicitamente uma coleção, poderá usar qualquer uma das read concerns disponíveis para transações.
Se não especificado no início da transação, as transações usam a read concern no nível de sessão ou, se isso não estiver definido, a read concern no nível de cliente.
Para obter mais informações, consulte Transação Read Concern.
Sessões causalmente consistentes e read concerns disponíveis
Para operações em uma sessão causalmente consistente, os níveis "local", "majority" e "snapshot" estão disponíveis. No entanto, para garantir a consistência causal, você deve usar "majority". Para obter detalhes, consulte Consistência causal.
Operações que apoiam a read concern
As seguintes operações suportam a read concern:
Importante
Para definir a read concern para operações em uma transação, defina a read concern no nível de transação, não no nível de operação individual. Não defina explicitamente a read concern para as operações individuais em uma transação. Para obter mais informações, consulte Transações and Read Concern.
| [1] | Não é possível usar o stage $out ou $merge em conjunto com a read concern "linearizable". Ou seja, se você especificar "linearizable" read concern para db.collection.aggregate(), não poderá incluir nenhum dos estágios no pipeline. |
| [2] | Read concern "snapshot" está disponível apenas para determinadas operações de leitura e para transações de vários documentos. Em uma transação, você não pode usar o comando distinct ou seus ajudantes em uma coleta fragmentada. |
As seguintes operações de escrita também podem aceitar uma read concern se fizerem parte de uma transação multidocumento:
Importante
Para definir a read concern para operações em uma transação, defina a read concern no nível de transação, não no nível de operação individual.
Comando | |||||
|---|---|---|---|---|---|
✓ | ✓ | ||||
✓ | ✓ | ||||
✓ | ✓ | ||||
✓ | ✓ | ||||
✓ | |||||
✓ |
| [3] | (1, 2) A área de leitura "snapshot" está disponível somente para determinadas operações de leitura e transações com vários documentos. Para transações, você define a read concern no nível de transação. As operações de transação que suportam "snapshot" correspondem às operações CRUD disponíveis nas transações. Para obter mais informações, consulte Transactions and Read Concern. |
Read concern não suportada no local banco de dados
O banco de dados local não suporta questões de leitura. O MongoDB ignora silenciosamente qualquer read concern configurada para uma operação em uma coleção no banco de dados local.
Considerações
Leia seus próprios escritos
Você pode usar sessões causalmente consistentes para ler suas próprias gravações, se as gravações solicitarem confirmação.
Ordem em tempo real
Combinada com "majority" write concern, "linearizable" read concern permite que vários threads realizem leituras e gravações em um único documento como se um único thread executasse essas operações em tempo real; ou seja, o cronograma correspondente para essas leituras e gravações é considerado linearizável.
Comparações de desempenho
Ao contrário "majority", "linearizable" read concern confirma com membros secundários que a operação de leitura é leitura de um primário que é capaz de confirmar gravações com { w: "majority" } write concern. [4] Como tal, leituras com read concern linearizável podem ser significativamente mais lentas do que leituras com read concerns "majority" "local".
Sempre use maxTimeMS com read concern linearizável caso
a maioria dos membros portadores de dados não esteja disponível. maxTimeMS garante que a operação não bloqueie indefinidamente e, em vez disso, garante que a operação retorne um erro se a read concern não puder ser executada.
Por exemplo:
db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000) db.runCommand( { find: "restaurants", filter: { _id: 5 }, readConcern: { level: "linearizable" }, maxTimeMS: 10000 } )
| [4] | Em alguns casos, dois nós em um conjunto de réplicas podem acreditar transitoriamente que são os primários, mas somente um deles poderá realizar gravações com restrição de gravação { w:
"majority" }. O nó que consegue realizar gravações { w: "majority" } é o primário atual, e o outro nó é um antigo primário que ainda não reconheceu seu rebaixamento, normalmente devido a uma partição de rede. Quando isso ocorre, os clientes que se conectam ao antigo primário poderão ver dados obsoletos, apesar de terem solicitado uma preferência de leitura primary, e novas gravações no antigo primário acabarão sendo revertidas. |
Ler operações e afterClusterTime
O MongoDB inclui suporte para sessões causalmente consistentes. Para operações de leitura associadas a sessões causalmente consistentes, o MongoDB oferece suporte à opção de preocupação de leitura afterClusterTime a ser definida automaticamente pelos drivers para operações associadas a sessões causalmente consistentes.
Importante
Não defina manualmente afterClusterTime para uma operação de leitura. Os drivers do MongoDB definem esse valor automaticamente para operações associadas a sessões causalmente consistentes. No entanto, você pode adiantar o tempo de operação e o tempo de cluster para a sessão, de modo a ser consistente com as operações de outra sessão de cliente. Para obter um exemplo, consulte Exemplos.
Observação
Não é possível especificar atClusterTime em conjunto com afterClusterTime. Para usar o atClusterTime com a read concern "snapshot", é necessário desativar as sessões causalmente consistentes.
Para satisfazer uma solicitação de leitura com um valor afterClusterTime de T, um mongod deve executar a solicitação depois que seu oplog atingir o tempo T. Caso seu oplog não tenha atingido o tempo T, o mongod deve aguardar para atender a solicitação.
As operações de leitura com um afterClusterTime especificado retornam dados que atendem ao requisito de nível de preocupação de leitura e ao requisito afterClusterTime especificado.
Para operações de leitura não associadas a sessões causalmente consistentes, afterClusterTime não está definido.
Read concern do Provenance
O MongoDB rastreia a preocupação de leitura provenance, que indica a origem de uma preocupação de leitura específica. Você pode ver provenance nas métricas getLastError, preocupação de leitura error objects e logs do MongoDB.
A tabela a seguir mostra os possíveis valores de read concern provenance e seu significado:
Proveniência | Descrição |
|---|---|
clientSupplied | O read concern foi especificado no aplicativo. |
customDefault | A read concern originou-se de um valor padrão
personalizado definido. Consulte setDefaultRWConcern. |
implicitDefault | A read concern a originou-se do servidor na ausência
de todas as outras especificações de read concern. |