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 nó ativo de nenhuma lista. Todos os nós começam nesse estado. O `mongod` analisa o documento de configuração do conjunto de réplicas enquanto está em `STARTUP`.
1	`PRIMARY`	O membro no estado primário é o único membro que pode aceitar operações de gravação. Elegível para votar.
2	`SECONDARY`	Um membro no estado secundário está replicando o armazenamento de dados. Elegível para votar.
3	`RECOVERING`	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	`STARTUP2`	O membro está executando uma sincronização inicial. Elegível para votar, exceto quando adicionado recentemente ao conjunto de réplicas.
6	`UNKNOWN`	O estado do membro, como visto de outro membro do conjunto, ainda não é conhecido.
7	`ARBITER`	Os árbitros não replicam dados e existem apenas para participar de eleições. Elegível para votar.
8	`DOWN`	O membro, como visto de outro membro do conjunto, não está acessível.
9	`ROLLBACK`	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 elimina todas as operações do usuário em andamento quando um nó entra no estado `ROLLBACK` .
10	`REMOVED`	Este membro já esteve em um conjunto de réplicas, mas foi removido posteriormente.

Estados

Estados centrais

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

SECONDARY: Os nós no estado SECONDARY replicam o conjunto de dados do primário 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 primário se tornar indisponível.

ARBITER: Os nós no estado ARBITER não replicam 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 nó no estado ARBITER se o conjunto tivesse um número par de nós votantes e pudesse sofrer de eleições vinculadas. Deve haver, no máximo, um árbitro configurado em qualquer conjunto de réplicas. Para considerações ao usar um árbitro, consulte árbitro do conjunto de réplicas.

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

Outros estados

STARTUP: Cada nó de um conjunto de réplicas é iniciado no estado STARTUP. mongod então carrega a configuração do conjunto de réplicas do nó e transita o estado do nó para STARTUP2 ou ARBITER. Nós em STARTUP não são elegíveis para votar, pois ainda não são nós 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.

Então, o membro 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 disso, o membro faz a transição para RECOVERING.

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

RECOVERING

Um nó de um conjunto de réplicas entra no 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 nós 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 nó 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. O estado SECONDARY não garante nada sobre a obsolescência dos dados com relação ao primário.

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

ROLLBACK

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

A partir da versão 4.2, O MongoDB elimina todas as operações do usuário em andamento quando um nó entra no estado ROLLBACK .

Estados de erro

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

Voltar

Versão do protocolo

Implemente e gerencie clusters fragmentados autogerenciados