Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ /

Preocupação de leitura "majority"

Nesta página

  • Desempenho
  • Disponibilidade
  • Exemplo
  • Suporte ao mecanismo de armazenamento
  • Read concern "majority" e Transações
  • Read concern "majority" e a agregação
  • Leia seus próprios escritos
  • Conjuntos de réplicas Primary-Secondary-Arbiter
"majority"

Para operações de leitura não associadas àstransações multidocumento , a read concern "majority" garante que os dados lidos foram reconhecidos pela maioria dos membros do conjunto de réplicas. Os documentos lidos são duráveis e garantem que não sejam revertidos.

Para operações em transações multidocumento, a preocupação de leitura"majority" fornece suas garantias somente se a transação for confirmada com a preocupação de gravação "maioria". Caso contrário, a preocupação de leitura "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.

Para obter mais informações sobre o que acontece se um primário falhar,consulte failover automático.

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 desempenho a outras read concerns.

A preocupação de leitura "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:

  • A preocupação de gravação "majority" pode causar problemas de desempenho se um secundário não estiver disponível ou estiver atrasado. Para obter conselhos sobre como mitigar esses problemas, consulte Atenuar problemas de desempenho com um conjunto de réplicas de PSA autogerenciado.

  • Se você estiver usando um padrão global "majority" e a preocupação de gravação for menor que o tamanho da maioria, suas queries poderão retornar dados obsoletos (não totalmente replicados).

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.

Linha do tempo de uma operação de gravação para um conjunto de réplicas de três membros.
Hora
Evento
Escrita mais recente
Mais recente w: escrita da "maioria"
t 0
Primário aplica Write 0
Primary: Write 0
Secondary 1: Write prev
Secondary 2: Write prev
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t 1
O secundário 1 aplica a gravação 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write prev
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t 2
O secundário 2 aplica a escrita 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev
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: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write prev
Secondary 2: Write prev
t 4
O primary está ciente da replicação bem-sucedida para o secundário 2
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write prev
Secondary 2: Write prev
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: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write prev
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: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0

Depois, as tabelas a seguir resumem o estado dos dados que uma operação de leitura com a preocupação de leitura "majority" veria no momento T.

Linha do tempo de uma operação de escrita para um conjunto de réplica de três membros.
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

A preocupação de leitura "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" read concern.

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 multidocumento, a preocupação de leitura "majority" fornece suas garantias somente se a transação for confirmada com a preocupação de gravação "maioria". Caso contrário, a preocupação de leitura "majority" não oferece garantias sobre os dados lidos nas transações.

Você pode especificar o nível de preocupação de leitura "majority" para uma agregação que inclui um estágio de $out.

Você pode usar sessões causalmente consistentes para ler suas próprias gravações, se as gravações solicitarem confirmação.

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:

Voltar

"available"