Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Preocupação de leitura "linearizable"
"linearizable"
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.
Read concern linearizável apenas se aplica se operações de leitura especificarem um filtro de query que exclusivamente identifique um único documento.
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.
Sessões causalmente consistentes
A preocupação de leitura "linearizable" não está disponível para uso com sessões causais consistentes.
Restrição de aggregation
Não é possível usar o estágio $out ou $merge em conjunto com a "linearizable" read concern. Ou seja, se você especificar a read concern "linearizable" para db.collection.aggregate(), não poderá incluir nenhum dos estágios no pipeline.
Ordem em tempo real
Combinada com "majority" write concern, "linearizable" read concern 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; ou seja, o cronograma correspondente para essas leituras e gravações é considerado linearizável.
Leia seus próprios escritos
Alterado na versão 3.6.
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.
Comparações de desempenho
Ao contrário "majority", read concern "linearizable" confirma com membros secundários que a operação de leitura está lendo de um primary que é capaz de confirmar escritas com write concern { w: "majority" } [1] Dessa forma, as leituras com read concern linearizável podem ser significativamente mais lentas do que as leituras com preocupações de leitura "majority" ou "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 } )
| [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 { 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. |