Preocupação de leitura "linearizable"
Novidade na versão 3.4.
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
Você não pode usar o estágio $out ou $merge em conjunto com a preocupação de leitura "linearizable". Ou seja, se você especificar "linearizable" preocupação de leitura para db.collection.aggregate(), não poderá incluir nenhum dos estágios no pipeline.
Ordem em tempo real
Combinado com a preocupação de gravação do "majority", a preocupação de leitura do "linearizable" permite que várias threads realizem leituras e gravações em um único documento como se uma única thread executasse essas operações em tempo real; ou seja, o cronograma correspondente dessas leituras e gravações é considerado linearizável.
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
Diferentemente de "majority", a preocupação de leitura "linearizable" confirma com os nós secundários que a operação de leitura está sendo feita a partir de um primário capaz de confirmar gravações com a preocupação de gravação { w: "majority" }. [1] Dessa forma, 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 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. |