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.
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
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. |