Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Preocupação de leitura "majority"
Nesta página
"majority"
Para operações de leitura não associadas a transações com vários documentos, o read concern "majority" garante que os dados lidos foram reconhecidos pela maioria dos membros do conjunto de réplicas (ou seja, os documentos lidos são duráveis e têm garantia de não serem revertidos).
Para operações em transações com vários documentos, read concern "majority" fornece suas garantias somente se a transação for confirmada com write concern "maioria". Caso contrário, a read concern "majority" não oferece garantias sobre os dados lidos nas transações.
Independentemente do nível de read concern, os dados mais recentes em um nó podem não refletir a versão mais recente dos dados no sistema.
Desempenho
Cada membro do conjunto de réplica mantém, em memória, uma visualização dos dados no ponto de confirmação principal; o ponto de confirmação principal é calculado pelo principal. Para atender à read concern "majority", o nó retorna dados dessa visualização e é comparável em custo de desempenho a outras questões de leitura.
Disponibilidade
Leia a preocupação "majority" está disponível para uso com ou sem sessões e transações causalmente consistentes.
Aviso
Se você estiver usando uma arquitetura PSA (primária-secundária-arbiter) de três membros, considere o seguinte:
O write concern
"majority"pode causar problemas de desempenho se um secundário não estiver disponível ou estiver atrasado. Para obter conselhos sobre como atenuar esses problemas, consulte Atenuar problemas de desempenho com o conjunto de réplicas PSA.Se você estiver usando um
"majority"padrão global e o write concern for menor que o tamanho da maioria, suas consultas poderão retornar dados obsoletos (não totalmente replicados).
Exemplo
Considere a seguinte linha do tempo de uma operação de gravação Escrever 0 para um conjunto de réplicas de três membros:
Observação
Para simplificar, o exemplo pressupõe:
Todas as gravações anteriores à gravação 0 foram replicadas com sucesso para todos os membros.
Escrever prev é a escrita anterior antes de Escrever 0.
Nenhuma outra gravação ocorreu após Write 0.
Hora | Evento | Escrita mais recente | Mais recente w: escrita da "maioria" |
|---|---|---|---|
t 0 | Primário aplica Write 0 | Primary: escrever 0 secundário 1: Escrever anterior secundário 2: Escrever anterior | Primary: escrever anterior secundário 1: Escrever anterior secundário 2: Escrever anterior |
t 1 | O secundário 1 aplica a gravação 0 | Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escrever anterior | Primary: escrever anterior secundário 1: Escrever anterior secundário 2: Escrever anterior |
t 2 | O secundário 2 aplica a escrita 0 | Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0 | Primary: escrever anterior secundário 1: Escrever anterior secundário 2: Escrever anterior |
t 3 | O Primário está ciente do sucesso da replicação para o Secundário 1 e envia uma confirmação ao cliente | Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0 | Primary: escrever 0 secundário 1: Escrever anterior secundário 2: Escrever anterior |
t 4 | O primary está ciente da replicação bem-sucedida para o secundário 2 | Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0 | Primary: escrever 0 secundário 1: Escrever anterior secundário 2: Escrever anterior |
t 5 | O secundário 1 recebe um aviso (por meio de mecanismo de replicação regular) para atualizar o snapshot de sua gravação w: "maioria" mais recente | Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0 | Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escrever anterior |
t 6 | O secundário 2 recebe um aviso (por meio do mecanismo de replicação regular) para atualizar seu snapshot do w mais recente: "majority" write | Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0 | Primary: escrever 0 secundário 1: Escreva 0 secundário 2: Escreva 0 |
Depois, as tabelas a seguir resumem o estado dos dados que uma operação de leitura com "majority" read concern veria no momento T.
Meta de leitura | Hora T | Estado dos dados |
|---|---|---|
Principal | Antes de 3 | Os dados refletem a gravação anterior |
Principal | Após t 3 | Os dados refletem Gravação 0 |
Secundário 1 | Antes de 5 | Os dados refletem a gravação anterior |
Secundário 1 | Após t 5 | Os dados refletem Gravação 0 |
Secundário 2 | Antes ou às 6 | Os dados refletem a gravação anterior |
Secundário 2 | Após t 6 | Os dados refletem Gravação 0 |
Suporte ao mecanismo de armazenamento
Read concern a "majority" está disponível para o mecanismo de armazenamento WiredTiger.
Dica
O comando serverStatus retorna o campo storageEngine.supportsCommittedReads que indica se o mecanismo de armazenamento suporta "majority" questões de leitura.
Leia a preocupação "majority" e as transações
Observação
Você define a preocupação de leitura no nível da transação, não no nível da operação individual. Para definir a preocupação de leitura para transações, consulte Transações e preocupação de leitura.
Para operações em transações com vários documentos, read concern "majority" fornece suas garantias somente se a transação for confirmada com write concern "maioria". Caso contrário, a read concern "majority" não oferece garantias sobre os dados lidos nas transações.
Read concern "majority" e agregação
A partir do MongoDB 4.2, você pode especificar o nível de read concern "majority" para uma agregação que inclui um estágio $out .
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.
Conjuntos de réplicas Primary-Secondary-Arbiter
A partir do MongoDB 5.0, enableMajorityReadConcern e --enableMajorityReadConcern não podem ser alterados e são sempre definidos como true devido a melhorias no mecanismo de armazenamento.
Em versões anteriores do MongoDB, enableMajorityReadConcern e --enableMajorityReadConcern são configuráveis e podem ser configurados como false para evitar que a pressão do cache de armazenamento imobilize um sistema com uma arquitetura PSA (primary-secondary-arbiter) de três membros.
Se você estiver usando uma arquitetura PSA (primária-secundária-arbiter) de três membros, considere o seguinte:
O write concern
"majority"pode causar problemas de desempenho se um secundário não estiver disponível ou estiver atrasado. Para obter conselhos sobre como atenuar esses problemas, consulte Atenuar problemas de desempenho com o conjunto de réplicas PSA.Se você estiver usando um
"majority"padrão global e o write concern for menor que o tamanho da maioria, suas consultas poderão retornar dados obsoletos (não totalmente replicados).