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 seu sistema não tem um primary executando replSetGetStatus rs.status() o método ou. O exemplo a seguir mostra a saída do rs.status() método 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 rs.status() saída mostra ostateStr valor de alguns UNKNOWN membros DOWN como ou.

Verifique as mensagens de registro

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

mensagem	Descrição
"Iniciando uma eleição, já que não vimos nenhum PRIMARY 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 seu sistema eleja um primário.

Partição de rede

Se seu sistema 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 seu sistema é afetado por uma partição de rede, execute o método replSetGetStatus ou 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.rs.status()

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 centro de dados principal contenha um quorum de membros votantes e membros qualificados para serem primários. Se o primary do seu conjunto de réplicas ficar inativo e nenhum dos secundários for eleito para se tornar o primary, verifique se os nós restantes não são todos nós 0 prioridade.

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

// 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 primary devido à sua prioridade, atualize o members[n].priority valor 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 seu sistema 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 collections 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 Disk Usage gráfico, disponível no monitoramento de cluster do.
Em implementações autogerenciadas, execute o dbStats comando ou db.stats() o método.

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 membro faça backup.

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 primary. 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 um sistema com dois nós portadores de dados e um nó oculto sem direito a voto. Se um membro portador de dados falhar, os membros restantes não poderão formar uma maioria.

Em uma topologia PSA (primary-secondary-arbiter) que usa preocupação de gravação, se o secundário "majority" 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 o 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" preocupação de gravação para impedir que as gravações sejam bloqueadas indefinidamente.

Para obter mais detalhes sobre a mitigação de problemas de desempenho em topologias PSA, consulte Atenuar problemas de desempenho com um conjunto de réplicas PSA autogerenciado.

Em uma topologia primary-secondary-secondary-arbiter (PSSSA), colocar a maioria dos membros votantes em um único centro de dados ou site de recuperação de desastres (DR) cria um risco de perda de maioria. Se essa região cair completamente, os membros restantes não poderão formar uma maioria e não poderão eleger uma primária. 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 Conscientização sobre data centers.

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