Solucionar problemas de eleições frequentes

Queries ineficientes

Para verificar se seu sistema está esgotando recursos devido a queries ineficientes:

1. Procure entradas em seus registros em que o valor do componente ("c") COMMAND seja.

2. Para cada entrada, o campo bytesRead indica quantos bytes um determinado comando lê. Preste atenção aos comandos com valores bytesRead grandes.

3. Se os registros de data/hora de suas queries ineficientes ocorrerem próximos aos registros de data/hora de múltiplas eleições, as queries ineficientes provavelmente estão causando suas eleições frequentes.

Use os seguintes recursos para otimizar suas queries:

• Administre seu volume de trabalho com mais eficiência usando índices compostos.

• Revise nossa diretriz ESR para criar novos índices.

• No Atlas, revise seu consultor de desempenho regularmente para obter sugestões de índice com base em seu volume de trabalho mais recente.

Prioridade de nó

Os conjuntos de réplicas convocam eleições continuamente até que elejam o membro com a maior prioridade. Se você não definir as prioridades dos membros adequadamente, as eleições podem ocorrer com mais frequência, com membros inesperados se tornando primários.

Para verificar os valores de prioridade de cada membro, execute o replSetGetConfig comando ou rs.conf() o método. O exemplo a seguir mostra a saída do rs.conf() método para um conjunto de réplicas com prioridades configuradas incorretamente:

rs.conf().members

[
   {
      _id: 0,
      host: "rs0-0.example.net:27017",
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 1,
      tags: { dc: "primaryDC" },
      secondaryDelaySecs: Long(0),
      votes: 1
   },
   {
      _id: 1,
      host: "rs0-1.example.net:27017",
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 10,
      tags: { dc: "remoteDC1" },
      secondaryDelaySecs: Long(0),
      votes: 1
   },
   {
      _id: 2,
      host: "rs0-2.example.net:27017",
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 9,
      tags: { dc: "remoteDC2" },
      secondaryDelaySecs: Long(0),
      votes: 1
   },
   {
      _id: 3,
      host: "rs0-3.example.net:27017",
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 8,
      tags: { dc: "analyticsDC" },
      secondaryDelaySecs: Long(0),
      votes: 1
   }
]

No exemplo acima, o primário atual tem menor prioridade do que os outros três membros. Se um secundário de alta prioridade estiver íntegro e estiver no estado SECUNDÁRIO, ele pode desencadear uma eleição para assumir o controle como primary.

Certifique-se de configurar adequadamente as prioridades para os membros do conjunto de réplicas:

• Atribua a maior prioridade ao servidor que você deseja servir consistentemente como principal

• Atribua prioridades padrão ou inferiores a outros membros para reduzir sua probabilidade de se tornarem primários

• Atribuir nós com alta prioridade de atraso de replicação baixa

Configurações de conjunto de réplicas

Para verificar as definições de configuração do conjunto replSetGetConfig de réplicas, execute o comando ou rs.conf() o método. O exemplo a seguir mostra um conjunto de réplicas com electionTimeoutMillis configurado muito baixo:

rs.conf().settings

{
   chainingAllowed: true,
   heartbeatIntervalMillis: 2000,
   heartbeatTimeoutSecs: 10,
   electionTimeoutMillis: 1500,   // lower than a single heartbeat cycle
   catchUpTimeoutMillis: 2000,
   getLastErrorModes: { },
   getLastErrorDefaults: {
      w: 1,
      wtimeout: 0
   },
   replicaSetId: ObjectId("58858acc1f5609ed986b641b")
}

Certifique-se settings.electionTimeoutMillis de que o valor para não seja muito baixo. No exemplo acima, o settings.electionTimeoutMillis valor é menor que. Isso significa que um nó pode declarar o primário "inativo" antes da conclusão de um intervalo de pulsação completo, causando eleições settings.heartbeatIntervalMillis desnecessárias.