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

Estados-membros do conjunto de réplicas

Cada membro de um conjunto de réplicas tem um estado.

Número
Nome
Descrição do estado
0
STARTUP
Ainda não é um membro ativo de nenhuma lista. Todos os membros começam neste estado. O mongod analisa o documento de configuração do conjunto de réplicas enquanto está em STARTUP.
1
O membro no estado primário é o único membro que pode aceitar operações de gravação. Elegível para votar.
2
Um membro no estado secundário está replicando o armazenamento de dados. Elegível para votar.
3
Os membros realizam autoverificações de inicialização ou fazem a transição após a conclusão de um rollback ou ressincronização. Não há dados disponíveis para leituras deste membro. Elegível para votar.
5
O nó está executando uma sincronização inicial. Elegível para votar, exceto quando recém-adicionado ao conjunto de réplicas.
6
O estado do membro, como visto de outro membro do conjunto, ainda não é conhecido.
7
Os árbitros não replicam dados e existem apenas para participar de eleições. Elegível para votar.
8
O membro, como visto de outro membro do conjunto, não está acessível.
9

Este membro está executando ativamente uma reversão. Elegível para votar. Os dados não estão disponíveis para leituras deste membro.

A partir da versão 4.2, o MongoDB mata todas as operações de usuário em andamento quando um membro insere o estado ROLLBACK .

10
Este membro já esteve em um conjunto de réplicas, mas foi removido posteriormente.
PRIMARY

Membros em PRIMARY estado aceitam operações de gravação. Um conjunto de réplicas possui no máximo um primário por vez. [1] Um membro SECONDARY torna-se primário após uma eleição. Membros do estado PRIMARY são elegíveis para votar.

SECONDARY

Os membros no estado SECONDARY replicam o conjunto de dados do primary e podem ser configurados para aceitar operações de leitura. Os secundários são elegíveis para votar nas eleições e podem ser eleitos para o estado PRIMARY se o primary se tornar indisponível.

ARBITER

Os membros no estado do ARBITER não replicam os dados ou aceitam operações de gravação. Eles são elegíveis para votar e existem apenas para quebrar um vínculo durante as eleições. Os conjuntos de réplicas só devem ter um membro no estado ARBITER se o conjunto tivesse um número par de membros votantes e pudesse sofrer de eleições vinculadas. Deve haver, no máximo, um arbiter configurado em qualquer conjunto de réplicas. Para saber como usar um arbiter, consulte Conjunto de réplicas de arbiter.

Consulte Membros do conjunto de réplicas para obter mais informações sobre os estados principais.

STARTUP

Cada membro de uma réplicas configurada começa no estado STARTUP . mongod então carrega a configuração do conjunto de réplicas do membro e transita o estado do membro para STARTUP2 ou ARBITER. Membros em STARTUP não são elegíveis para votar, pois ainda não são membros reconhecidos de nenhum conjunto de réplicas.

STARTUP2

Alterado na versão 5.0.

Cada membro portador de dados de um conjunto de réplicas entra no estado STARTUP2 assim que mongod termina de carregar a configuração desse membro.

O membro então decide se quer ou não realizar uma sincronização inicial. Se um membro iniciar uma sincronização inicial, o membro permanecerá no STARTUP2 até que todos os dados sejam copiados e todos os índices sejam construídos. Depois, o membro faz a transição para RECOVERING.

Membros recém-adicionados em STARTUP2 não estão qualificados para votar e não podem ser eleitos durante o processo inicial de sincronização. Antes do MongoDB 5.0, os membros em STARTUP2 eram elegíveis para votar.

RECOVERING

Um membro de um conjunto de réplicas insere o estado RECOVERING quando não está pronto para aceitar leituras. O estado RECOVERING pode ocorrer durante a operação normal e não reflete necessariamente uma condição de erro. Os membros no estado RECOVERING são elegíveis para votar nas eleições, mas não são elegíveis para entrar no estado PRIMARY .

Um membro faz a transição de RECOVERING para SECONDARY depois de replicar dados suficientes para garantir uma visualização consistente dos dados para leituras do cliente. A única diferença entre os estados RECOVERING e SECONDARY é que RECOVERING proíbe leituras do cliente e SECONDARY as permite. SECONDARY não garante nada sobre a rigidez dos dados com relação ao primário.

Devido à sobrecarga, um secundário pode ficar suficientemente atrasado em relação aos outros membros do conjunto de réplicas, de modo que pode ser necessário sincronizar novamente com o restante do conjunto. Quando isso acontece, o membro entra no estado RECOVERING e requer intervenção manual.

ROLLBACK

Sempre que o conjunto de réplicas substitui um primary em uma eleição, o antigo primary pode conter documentos que não foram replicados para os membros secundários . Nesse caso, o membro primary antigo reverte essas gravações. Durante o rollback, o membro terá o estado ROLLBACK . Os membros do estado ROLLBACK são elegíveis para votar nas eleições.

A partir da versão 4.2, o MongoDB mata todas as operações de usuário em andamento quando um membro insere o estado ROLLBACK .

Os membros em qualquer estado de erro não podem votar.

UNKNOWN

Os membros que nunca comunicaram informações de status ao conjunto de réplicas estão no estado UNKNOWN .

DOWN

Os membros que perdem a conexão com o conjunto de réplicas são vistos como DOWN pelos demais membros do conjunto.

REMOVED

Os membros que são removidos do conjunto de réplicas entram no estado REMOVED . Quando os membros inserem o estado REMOVED , os registros marcarão esse evento com uma entrada de mensagem replSet REMOVED .

[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.
← O banco de dados local