Solucionar problemas de conjuntos de réplicas sem primário

Os conjuntos de réplicas podem ocasionalmente entrar em um estado onde não existe nenhum primário, normalmente durante as eleições. No entanto, quando nenhum primário existe por um longo período, o conjunto de réplicas não pode aceitar gravações.

Esta página contém problemas comuns e resoluções para solucionar problemas de conjuntos de réplicas que não têm primário por um longo período. Se você precisar de suporte adicional depois de passar pelas seções a seguir, entre em contato com o Suporte técnico.

Verificações de pré-requisitos

Verifique se sua implantação não tem um primário executando o método replSetGetStatus ou rs.status(). O exemplo a seguir mostra a saída do método rs.status() para um conjunto de réplicas sem primário:

rs.status().members

[
   {
      _id: 0,
      name: 'localhost:27018',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      ...
      configVersion: 2,
      configTerm: 6,
      self: true,
      lastHeartbeatMessage: ''
   },
   {
      _id: 1,
      name: 'localhost:27019',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      ...
      configVersion: 2,
      configTerm: 6
             },
             {
      _id: 2,
      name: 'localhost:27020',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      ...
      configVersion: 2,
      configTerm: 6
             }
     ]

Observação

Em alguns casos, você pode ver que a saída rs.status() mostra o valor stateStr de alguns membros como UNKNOWN ou DOWN.

Verifique as mensagens de log

Verifique as mensagens de log de sua implantação para entradas onde o valor do componente ("c") é ELECTION. Aqui, você pode encontrar repetidas tentativas de iniciar eleições que falham com as seguintes mensagens no campo "msg" :

mensagem	Descrição
"Iniciando uma eleição, já que não vimos nenhum primário no período de tempo limite da eleição "	Registrado por outros membros quando o primário desce.
"tivemos votos insuficientes"	Indica que a maioria dos nós não atendeu à solicitação de eleição . Os membros podem estar inativos ou pode ter ocorrido uma partição de rede .
"não consegue ver a maioria do conjunto, abandonando o primary"	Os membros podem estar inativos ou pode ter ocorrido uma partição de rede .

Problemas e Resoluções Comuns

A seção a seguir descreve problemas comuns que podem fazer com que um conjunto de réplicas tenha dificuldade em eleger um novo primário e como resolvê-los. Antes de entrar em contato com o suporte, verifique se os problemas a seguir impedem que sua implantação eleja um primário.

Partição de rede

Se sua implantação tiver uma partição de rede, os nós não poderão se comunicar uns com os outros, impedindo-os de eleger um primário.

Para verificar se sua implantação é afetada por uma partição de rede, execute o método replSetGetStatus ou rs.status() a partir de nós diferentes. Com base na saída de cada nó, identifique quais nós estão em cada lado da partição.

Para ajudar a restaurar a conectividade após uma partição:

Verifique as configurações do firewall para procurar regras que bloqueiem a comunicação entre membros.
Verifique os nomes de host DNS.
Certifique-se de adicionar seu endereço IP à sua lista de acesso IP.

Dica

Uma vez que a maioria dos nós pode alcançar uns aos outros, o MongoDB elege automaticamente um primário e as gravações são retomadas normalmente.

Nenhum secundário qualificado para promover

Certifique-se de que seu data center principal contenha um quorum de nós votantes e nós qualificados para serem primários. Se o primário do seu conjunto de réplicas ficar inativo e nenhum dos secundários for eleito para se tornar o primário, verifique se os nós restantes não são todos prioridade 0.

Para verificar os valores de prioridade de cada nó, execute o comando replSetGetConfig ou o método rs.conf():

// Returns an array of documents corresponding with each member in your replica set
rs.conf().members

[
   ...
   {
      _id: 1,
      host: localhost:27019,
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 0,
      tags: {},
      secondaryDelaySecs: Long('0'),
      votes: 1
   },
   ...
]

Se nenhum secundário estiver qualificado para se tornar primário devido à sua prioridade, atualize o valor members[n].priority de um ou mais secundários. Para obter instruções detalhadas, consulte Ajustar prioridade para um membro do conjunto de réplicas autogerenciado.

Esgotação de recursos

Se sua implantação tiver cargas de trabalho de gravação pesada, muitos índices ou processos de manutenção que ocupam espaço em disco significativo, você poderá sobrecarregar seus nós e causar falhas.

Para recuperar espaço em disco, considere:

Eliminar coleções ou bancos de dados não utilizados.
Remoção de índices duplicados ou não utilizados.

Para monitorar o uso do disco:

No Atlas, você pode visualizar o gráfico Disk Usage, disponível no monitoramento de cluster.
Em implementações autogerenciadas, execute o comando dbStats ou o método db.stats().

Perda da maioria

Se vários membros votantes diminuirem e o conjunto de réplicas perder sua maioria, a saída rs.status() poderá mostrar que todos os membros estão no estado SECONDARY ou RECOVERING . Os seguintes cenários podem causar perda de maioria:

Manutenção de rolagem realizada incorretamente

Por exemplo, considere um conjunto de réplicas de três membros em que você remove dois membros para manutenção ao mesmo tempo. Nesse cenário, o conjunto de réplicas perde a maioria e não pode eleger um novo primário até que o terceiro nó esteja novamente ativo.

Para evitar esse cenário, certifique-se de realizar a manutenção contínua em série, começando com membros secundários e terminando com o primário. Isso garante que um primário esteja sempre disponível. Para obter orientação sobre a manutenção do conjunto de réplicas, consulte Executar manutenção em membros do conjunto de réplicas autogerenciados.

Topologia de cluster subprovisionada

Por exemplo, considere uma implantação com dois nós portadores de dados e um nó oculto sem direito a voto. Se um nó portador de dados falhar, os nós restantes não poderão formar uma maioria.

Em uma topologia PSA (primary-secondary-arbiter) que usa "majority" write concern, se o secundário ficar inativo para manutenção, as gravações param. O primário não pode obter reconhecimento majoritário porque apenas um dos dois membros votantes portadores de dados está disponível. Sem tempo limite definido nas operações de gravação, as gravações são bloqueadas indefinidamente. Para mitigar isso:

Acelere as operações de escrita durante a período de manutenção para limitar o volume de gravações paralisadas.
Defina o parâmetro wtimeout em operações de gravação que usam "majority" write concern para impedir que as gravações sejam bloqueadas indefinidamente.

Para obter mais detalhes sobre como atenuar problemas de desempenho em topologias PSA, consulte Atenuar problemas de desempenho em conjuntos de réplicas de PSA autogerenciados.

Em uma topologia primary-secondary-secondary-arbiter (PSSSA), colocar a maioria dos membros votantes em um único data center ou site de recuperação de desastres (DR) cria um risco de perda de maioria. Se essa região cair completamente, os nós restantes não poderão formar uma maioria e não poderão eleger um primário. Distribua membros votantes entre regiões para que a maioria permaneça disponível após uma falha em uma única região. Para obter orientação, consulte Reconhecimento de data center.

Verificar resolução

Depois que sua implantação for restaurada e uma nova primária for eleita, a saída rs.status() mostrará que um de seus membros está no estado PRIMARY.

Diagnósticos a serem coletados para mais suporte

Se você não conseguir resolver o problema, entre em contato com o Suporte técnico com as seguintes informações de diagnóstico:

Mensagens de log relevantes
rs.config() saída
rs.status() saída

Problemas relacionados

Saiba mais

Voltar

Eleições frequentes

atraso de replicação