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 writeConcernMajorityJournalDefault estiver configurado para o estado padrão de true.
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.
Você pode especificar a read concern linearizável para operações de leitura somente no primary.
Dica
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.
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
_idou 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 .
Sessões causalmente consistentes
Read concern "linearizable" is unavailable for use with causally consistent sessions.
Restrição de aggregation
You cannot use the $out or the $merge stage in conjunction with read concern "linearizable". That is, if you specify "linearizable" read concern for db.collection.aggregate(), you cannot include either stages in the pipeline.
Ordem em tempo real
Combined with "majority" write concern, "linearizable" read concern enables multiple threads to perform reads and writes on a single document as if a single thread performed these operations in real time; that is, the corresponding schedule for these reads and writes is considered linearizable.
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.
Comparações de desempenho
Ao "majority" contrário, "linearizable" preocupação de leitura confirma com membros secundários que a operação de leitura está lendo de um primary que é capaz de confirmar escritas com preocupação { w: "majority" } de gravação. []1 Dessa forma, as leituras com preocupação de leitura linearizável podem ser significativamente mais lentas do que as leituras com "majority" preocupações de "local" leitura ou.
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 } )
| [1] | 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 |