Preocupação de leitura

Use a readConcern opção para controlar a consistência e o isolamento da leitura de dados 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. Por exemplo, você pode aguardar por garantias de consistência mais fortes ou afrouxar os requisitos de consistência para obter maior disponibilidade.

Conjuntos de réplicas e clusters fragmentados suportam uma preocupação de leitura padrão global. Operações sem uma preocupação de leitura explícita herdam o padrão global. Consulte para mais informações.setDefaultRWConcern

Níveis de preocupação de leitura

Os seguintes níveis de read concern estão disponíveis:

`level`	Descrição
`"local"`	A query retorna dados da instância sem garantia de que os dados tenham sido gravados na maioria dos membros do conjunto de réplicas. Os dados podem ser revertidos. Padrão para leituras em relação ao primário e aos secundários. Disponibilidade: read concern está disponível com ou sem sessões e transações causalmente `"local"` consistentes. Para mais informações, consulte a página de referência do `"local"`.
`"available"`	A query retorna dados da instância sem garantia de que os dados tenham sido gravados na maioria dos membros do conjunto de réplicas. Os dados podem ser revertidos. Disponibilidade: A read concern `"available"` está indisponívelpara uso com sessões e transações causalmente consistentes. Para clusters fragmentados, um read concern `"available"` fornece a menor latência de leitura possível entre as várias read concerns. No entanto, isso vem às custas da consistência, já que `"available"` read concern pode retornar documentos órfãos ao ler de uma coleção fragmentada. Para evitar o risco de retornar documentos órfãos ao ler de coleções fragmentadas, use uma read concern diferente, como a read concern `"local"`. Para mais informações, consulte a página de referência do `"available"`.
`"majority"`	A query retorna os dados confirmados por uma maioria dos membros do conjunto de réplica. Os documentos devolvidos são duráveis, mesmo que ocorra uma falha. Para executar `"majority"` a preocupação de leitura, o membro do conjunto de réplicas retorna dados de sua exibição na memória no ponto de confirmação de maioria . A read concern tem desempenho comparável a outras read `"majority"` concerns. Disponibilidade: read concern está disponível com ou sem sessões e transações causalmente `"majority"` consistentes. Requisitos: Os conjuntos de réplicas devem usar o mecanismo de armazenamento WiredTiger. Para transações com vários documentos, a preocupação de leitura `"majority"` fornece suas garantias somente se a transação for confirmada com a preocupação de gravação "maioria". Caso contrário, `"majority"` não oferece garantias sobre a leitura de dados em transações. Para mais informações, consulte a página de referência do `"majority"`.
`"linearizable"`	A query retorna dados que refletem todas as gravações bem-sucedidas reconhecidas pela maioria que foram concluídas antes do início da operação de leitura. A query pode esperar que as escritas simultâneas se propaguem para a maioria dos membros do conjunto de réplicas antes de retornar 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 serão duráveis se o estiver configurado para o valor `writeConcernMajorityJournalDefault` padrão `true` de. Com `writeConcernMajorityJournalDefault` definido como `false`, o MongoDB não espera que `w: "majority"` gravações sejam gravadas no registro em disco antes de reconhecer as gravações. Dessa forma, as operações de gravações `"majority"` poderiam ser revertidas no caso de uma perda transitória (por exemplo. falha e reinicialização) da maioria dos nós em determinado conjunto de réplicas. Disponibilidade: A read concern `"linearizable"` não está disponível para uso com sessões e transações causalmente consistentes. Você só pode especificar a preocupação de leitura linearizável para operações de leitura `primary` no. 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. 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: A query usa um campo imutável como chave de pesquisa da query. Por exemplo, pesquisando no campo `_id` ou usando `$natural`. Nenhuma atualização simultânea altera a chave de pesquisa da query. A chave de pesquisa tem um índice único e a query usa esse índice. 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 `maxTimeMS` com preocupação de leitura linearizável se a maioria dos membros portadores de dados não estiver disponível. `maxTimeMS` garante que a operação retorne um erro se a preocupação de leitura não puder ser executada, em vez de bloquear indefinidamente. Para mais informações, consulte a página de referência do `"linearizable"`.
`"snapshot"`	Uma query com read concern `"snapshot"` retorna dados comprometidos pela maioria como aparece nos fragmentos a partir de um único ponto específico no passado recente. A Read concern `"snapshot"` fornece suas garantias somente se a transação se ligar com a write concern `"majority"`. 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 está disponível `"snapshot"` para Todas as operações de leitura dentro de transações multidocumento, com a preocupação de leitura definida no nível de transação. Os seguintes métodos fora de transações multidocumento: `find` `aggregate` `distinct` somente em collections não fragmentadas Todas as outras operações de leitura proíbem `"snapshot"`.

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, defina a preocupação de leitura no nível da transação, não no nível de operação individual. As operações de transação usam preocupação de leitura no nível da transação. As read concerns definidas no nível da coleção e do banco de dados são ignoradas dentro da transação. Se você definir explicitamente a preocupação de leitura no nível da transação, a preocupação de leitura no nível do cliente também será ignorada.

Importante

Não defina explicitamente a preocupação de leitura para operações individuais. Para definir a preocupação de leitura para transações, consulte Read Concern/Write Concern/Read Preference.

Você pode definir o read concern no início da transação:

As transações multidocumento suportam os seguintes níveis de preocupação de leitura :
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 estão disponíveis. Para garantir a "snapshot" consistência causal, use. Para "majority" 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.

Comando/Método	`"local"`	`"available"`	`"majority"`	`"snapshot"` [3]	`"linearizable"`
`count`	✓	✓	✓		✓
`distinct`	✓	✓	✓	✓ [2]	✓
`find`	✓	✓	✓	✓	✓
`db.collection.find()` via `cursor.readConcern()`	✓	✓	✓	✓	✓
`getMore`	✓				✓
`aggregate` `db.collection.aggregate()`	✓	✓	✓	✓	✓ [3]
`Session.startTransaction()`	✓		✓	✓

[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	`"local"`	`"snapshot"` [3]
`delete` `db.collection.deleteOne()` `db.collection.deleteMany()` `db.collection.remove()`	✓	✓
`findAndModify` `db.collection.findAndModify()` `db.collection.findOneAndDelete()` `db.collection.findOneAndReplace()` `db.collection.findOneAndUpdate()`	✓	✓
`insert` `db.collection.insertOne()` `db.collection.insertMany()`	✓	✓
`update` `db.collection.updateOne()` `db.collection.updateMany()` `db.collection.replaceOne()`	✓	✓
`create` `db.createCollection()` (Requires FCV 6.0 or greater)	✓
`createIndexes` `db.collection.createIndex()` `db.collection.createIndexes()` (Requires FCV 6.0 or greater)	✓

[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, defina a preocupação de leitura 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.

Preocupação de leitura não suportada no banco de dados `local`

O banco de dados local não suporta questões de leitura. O MongoDB ignora silenciosamente qualquer preocupação de leitura configurado para operações em coleções 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 preocupação "majority" de gravação, "linearizable" preocupação de leitura permite que vários threads executem leituras e escritas em um único documento como se um único thread executasse essas operações em tempo real. O cronograma correspondente para essas leituras e escritas é considerado linearizável.

Comparações de desempenho

Ao contrário"majority", "linearizable"preocupação de leitura confirma com membros secundários que a operação de leitura lê de um primário capaz de confirmar gravações com{ w: "majority" }preocupação de gravação. [4] As leituras com preocupação de leitura linearizável podem ser significativamente mais lentas do que as leituras com preocupações de leitura"majority"ou"local".

Sempre use maxTimeMS com preocupação de leitura linearizável se a maioria dos membros portadores de dados não estiver disponível. maxTimeMS garante que a operação retorne um erro se a preocupação de leitura não puder ser executada, em vez de bloquear indefinidamente.

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 suporta sessões causalmente consistentes. Para operações de leitura em sessões causalmente consistentes, os drivers definem automaticamente a afterClusterTime opção de preocupação de leitura .

Importante

Não defina manualmente afterClusterTime para uma operação de leitura. Os drivers do MongoDB definem esse valor automaticamente para operações em 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 ver um exemplo, consulte Exemplos.

Observação

Você não pode especificar atClusterTime junto afterClusterTime com. Para usar o atClusterTime com a preocupação de "snapshot" leitura, desative as sessões causalmente consistentes.

Para atender a uma solicitação de leitura com um afterClusterTime valor de,T mongod deve executar a solicitação depois que seu oplog T atingir. Se seu oplog não T atingiu, aguarda para atender a mongod solicitação.

As operações afterClusterTime afterClusterTime de leitura com especificado retornam dados que atendem ao requisito de nível de preocupação de leitura e ao requisito 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 preocupação provenance de leitura, o que indica a origem de um preocupação de leitura. O provenance valor aparece nas getLastError métricas, objetos de erro de preocupação de leitura e registros 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.

Voltar

Objetos GeoJSON

"local"

Níveis de preocupação de leitura

readConcern Suporte

Opção de preocupação de leitura

Transações e preocupações de leitura disponíveis

Importante

Sessões causalmente consistentes e read concerns disponíveis

Operações que apoiam a read concern

Importante

Importante

Preocupação de leitura não suportada no banco de dados local

Considerações

Leia seus próprios escritos

Ordem em tempo real

Comparações de desempenho

Ler operações e afterClusterTime

Importante

Observação

Read concern do Provenance

`readConcern` Suporte

Preocupação de leitura não suportada no banco de dados `local`

Ler operações e `afterClusterTime`