Preocupação de leitura

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 read concern para o método mongosh db.collection.find(), use 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.

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:

  • "local"

  • "majority"

  • "snapshot"

• 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:

As seguintes operações de escrita também podem aceitar uma read concern se fizerem parte de uma transação multidocumento:

Read concern 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 read concern configurada para uma operação em uma coleção no banco de dados local.

Leia seus próprios escritos

A partir do MongoDB 3.6, você pode usar sessões causalmente consistentes para ler suas próprias gravações, se as gravações solicitarem reconhecimento.

Antes do MongoDB 3.6, para ler suas próprias gravações, você deve emitir sua operação de gravação com { w: "majority" } preocupação de gravação e, em seguida, emitir sua operação de leitura com primary preferência de leitura e "majority" ou "linearizable" preocupação de leitura.

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
} )

Ler operações e afterClusterTime

O MongoDB 3.6 introduz suporte para sessões causalmente consistentes. Para operações de leitura associadas a sessões causalmente consistentes, o MongoDB 3.6 apresenta a opção afterClusterTime read concern a ser definida automaticamente pelos drivers para operações associadas a 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 afterClusterTime especificado retornam dados que atendem ao requisito de nível de read concern 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 referência de leitura provenance, o que indica a origem de uma referência de leitura específica. Você pode ver provenance mostrado nas métricas getLastError, objeto de erro de referência de leitura e registros do MongoDB.

A tabela a seguir mostra os possíveis valores de read concern provenance e seu significado: