Solucionar problemas de conjuntos de réplicas

Nesta página

Verificar status do conjunto de réplicas

Verifique o atraso de replicação
Aplicação lenta de entradas Oplog
Conexões de teste entre todos os membros
Exceções de soquete ao reiniciar mais de um secundário
Verificar o tamanho do Oplog

Esta seção descreve estratégias comuns para solucionar problemas de implantações deconjuntos de réplicas.

Verificar status do conjunto de réplicas

Para exibir o estado atual do conjunto de réplicas e o estado atual de cada membro, execute o método rs.status() em uma sessão do mongosh que está conectada ao primário do conjunto de réplicas. Para descrições das informações exibidas por rs.status(), consulte replSetGetStatus.

Observação

O método rs.status() é um invólucro que executa o comando do banco de dados do replSetGetStatus.

Verifique o atraso de replicação

Atraso de replicação é um atraso entre uma operação no primário e a aplicação dessa operação do oplog para o secundário. O atraso de replicação pode ser um problema significativo e afetar seriamente as implementações de conjuntos de réplicas do MongoDB. Um atraso excessivo na replicação torna os membros "atrasados" inelegíveis para se tornarem primários rapidamente e aumenta a possibilidade de que as operações de leitura distribuída sejam inconsistentes.

Para verificar o comprimento atual do atraso de replicação:

Em uma sessão mongosh conectada ao primário, chame o método rs.printSecondaryReplicationInfo().

Retorna o valor syncedTo para cada membro, que mostra o horário em que a última entrada do oplog foi gravada no secundário, conforme mostrado no exemplo a seguir:

source: m1.example.net:27017
    syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary
source: m2.example.net:27017
    syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary

Um membro atrasado pode aparecer como 0 segundos atrás do primário quando o período de inatividade no primário for maior que o valor members[n].secondaryDelaySecs.

Observação

O método rs.status() é um invólucro em torno do comando replSetGetStatus do banco de dados.

A partir do MongoDB 7.0 (e 6.0.13, 5.0.24), o totalOplogSlotDurationMicros na mensagem de registro de query lenta mostra o tempo entre uma operação de gravação que obtém um carimbo de data/hora de confirmação para confirmar as gravações do mecanismo de armazenamento e a confirmação efetiva. mongod suporta gravações paralelas. No entanto, ele confirma operações de gravação com registros de data e hora de confirmação em qualquer ordem.

Exemplo

Considere as seguintes operações de escrita com carimbos de data/hora de função commit:

writeA com Timestamp1
writeB com Timestamp2
writeC com Timestamp3

Suponha que writeB seja confirmado primeiro em Timestamp2. A replicação é pausada até que writeA confirme porque a entrada oplog de writeA com Timestamp1 é necessária para que a replicação copie o oplog para membros secundários do conjunto de réplicas.

Monitore a taxa de replicação verificando valores de tempo de oplog diferentes de zero ou aumentando no gráfico de Replication Lag disponível no Cloud Manager e no Ops Manager.

Causas do atraso na replicação

As possíveis causas do atraso de replicação incluem:

Latência de rede
Verifique as rotas de rede entre os membros da sua configuração para garantir que não haja perda de pacote ou problema de roteamento de rede.
Use ferramentas, incluindo ping para testar a latência entre membros definidos e traceroute para expor o roteamento de pontos de rede de pacotes.
Taxa de transferência de disco
Se o sistema de arquivos e o dispositivo de disco no secundário não conseguirem liberar dados para o disco tão rapidamente quanto o principal, o secundário terá dificuldade em manter o estado. Problemas relacionados a disco são incrivelmente prevalentes em sistemas de vários inquilinos, incluindo instâncias virtualizadas, e podem ser transitórios se o sistema acessar dispositivos de disco em uma rede IP (como acontece com o sistema EBS da Amazon).
Use ferramentas no nível do sistema para avaliar o status do disco, incluindo iostat ou vmstat.
Concurrency
Em alguns casos, operações de longa duração no primário podem bloquear a replicação nos secundários. Para obter melhores resultados, configure a preocupação de gravação para exigir a confirmação da replicação para os secundários. Isso impede que as operações de gravação retornem se a replicação não puder acompanhar a carga de gravação.
Você também pode usar o profiler do banco de dados para verificar se há consultas lentas ou operações de longa duração que correspondam às incidências de atraso.
Preocupação de gravação apropriada
Se estiver realizando uma grande operação de ingestão de dados ou de carga em massa que exija um grande número de gravações no primário, especialmente com unacknowledged write concern, os secundários não conseguirão ler o oplog com rapidez suficiente para acompanhar as alterações.
Para evitar isso, solicite a confirmação de gravação da preocupação de gravação após cada 100, 1.000 ou outro intervalo para fornecer uma oportunidade para os secundários alcançarem o primário.
Para mais informações, veja:

Controle de fluxo

A partir do MongoDB 4.2, os administradores podem limitar a taxa na qual o primário aplica suas gravações com o objetivo de manter o atraso abaixo de um valor máximo majority committed configurável flowControlTargetLagSeconds.

Por padrão, o controle de fluxo é enabled.

Observação

Para que o controle de fluxo seja ativado, o conjunto de réplicas/cluster fragmentado deve ter: featureCompatibilityVersion (fCV) de 4.2 e preocupação de leitura majority enabled. Ou seja, o controle de fluxo ativado não terá efeito se fCV não for 4.2 ou se a maioria das preocupações de leitura estiver desativada.

Com o controle de fluxo ativado, à medida que o atraso se aproxima do flowControlTargetLagSeconds, as gravações no primário precisam obter tíquetes antes de usar os bloqueios para aplicar as gravações. Ao limitar o número de tíquetes emitidos por segundo, o mecanismo de controle de fluxo tenta manter o atraso abaixo da meta.

O atraso na replicação pode ocorrer sem que o conjunto de réplicas receba carga suficiente para acionar o controle de fluxo, como no caso de um secundário que não responde.

Para visualizar o status do controle de fluxo, execute os seguintes comandos no principal:

Execute o método rs.printSecondaryReplicationInfo() para determinar se algum nó está atrasado:

rs.printSecondaryReplicationInfo()

Saída de exemplo:

source: 192.0.2.2:27017
{
  syncedTo: 'Mon Jan 31 2022 18:58:50 GMT+0000 (Coordinated Universal Time)',
  replLag: '0 secs (0 hrs) behind the primary '
}
---
source: 192.0.2.3:27017
{
  syncedTo: 'Mon Jan 31 2022 18:58:05 GMT+0000 (Coordinated Universal Time)',
  replLag: '45 secs (0 hrs) behind the primary '
}

Execute o comando serverStatus e use o valor flowControl.isLagged para determinar se o conjunto de réplicas tem controle de fluxo engajado:
```
db.runCommand( { serverStatus: 1 } ).flowControl.isLagged
```
Saída de exemplo:
```
false
```
Se o controle de fluxo não estiver ativado, investigue o secundário para determinar a causa do atraso na replicação, como limitações no hardware, na rede ou no aplicativo.

Para obter informações sobre estatísticas de controle de fluxo, consulte:

Aplicação lenta de entradas Oplog

Os membros secundários de um conjunto de réplicas agora registram entradas de oplog que demoram mais do que o limite de operação lenta para serem aplicadas. Essas mensagens de atraso no oplog:

São registradas para os secundários no diagnostic log.
São registradas sob o componente REPL com o texto applied op: <oplog entry> took <num>ms.
Não dependem dos níveis de registro (seja no nível do sistema ou do componente)
Não dependem do nível de perfil.
São afetados por slowOpSampleRate.

O perfilador não captura entradas de oplog lentas.

Conexões de teste entre todos os membros

Todos os membros de um conjunto de réplicas devem ser capazes de se conectar a todos os outros membros do conjunto para dar suporte à replicação. Sempre verifique as conexões nas duas "direções". As topologias de rede e as configurações de firewall podem impedir a conectividade normal e necessária, o que pode bloquear a replicação.

Aviso

Antes de vincular sua instância a um endereço IP acessível publicamente, você deve proteger seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte Lista de verificação de segurança para implantações autogerenciadas. No mínimo, considere habilitar a autenticação e fortalecer a infraestrutura de rede.

Os binários do MongoDB, mongod e mongos, são vinculados ao host local por padrão. Se a configuração do arquivo de configuração net.ipv6 ou a opção de linha de comando --ipv6 estiver definida para o binário, o binário também será vinculado ao endereço IPv6 do host local.

Por padrão, mongod e mongos que estão vinculados a localhost só aceitam conexões de clientes executados no mesmo computador. Este comportamento vinculativo inclui mongosh e outros membros do seu conjunto de réplica ou cluster fragmentado. Clientes remotos não podem se conectar a binários vinculados apenas ao localhost.

Para substituir a associação padrão e vincular a outros endereços IP, use a net.bindIp configuração do arquivo de configuração ou a --bind_ip opção de linha de comando para especificar uma lista de nomes de host ou endereços IP.

Aviso

A partir do MongDB 5.0, DNS de horizonte dividido nós que são configurados apenas com um endereço IP falham na validação de inicialização e relatam um erro. Consulte disableSplitHorizonIPCheck.

Por exemplo, a instância mongod a seguir é vinculada ao host local e ao nome de host My-Example-Associated-Hostname, que está associado ao endereço IP 198.51.100.1:

mongod --bind_ip localhost,My-Example-Associated-Hostname

Para se conectar a esta instância, os clientes remotos devem especificar o nome do host ou seu endereço IP associado 198.51.100.1:

mongosh --host My-Example-Associated-Hostname
mongosh --host 198.51.100.1

Considere o seguinte exemplo de um teste bidirecional de rede:

Exemplo

Dado um conjunto de réplica com três membros em execução em três hosts separados:

m1.example.net
m2.example.net
m3.example.net

Todos os três usam a porta padrão 27017.

Teste a conexão de m1.example.net para os outros hosts com o seguinte conjunto de operação m1.example.net:
```
mongosh --host m2.example.net --port 27017
mongosh --host m3.example.net --port 27017
```
Teste a conexão de m2.example.net para os outros dois hosts com a seguinte operação definida de m2.example.net, como em:
```
mongosh --host m1.example.net --port 27017
mongosh --host m3.example.net --port 27017
```
Você agora testou a conexão entre m2.example.net e m1.example.net em ambas as direções.
Teste a conexão do m3.example.net para os outros dois hosts com a seguinte operação definida a partir do host do m3.example.net, como em:
```
mongosh --host m1.example.net --port 27017
mongosh --host m2.example.net --port 27017
```

Se alguma conexão, em qualquer direção, falhar, verifique a configuração de rede e firewall e reconfigure seu ambiente para permitir essas conexões.

Exceções de soquete ao reiniciar mais de um secundário

Ao reinicializar membros de um conjunto de réplicas, certifique-se de que o conjunto possa eleger um primário durante a manutenção. Isso significa garantir que a maioria dos members[n].votes do conjunto esteja disponível.

Quando os membros ativos de um conjunto não podem mais formar uma maioria, o conjunto primário deixa de ser e se torna um secundário. O primário não fecha as conexões do cliente quando desce.

Os clientes não podem gravar no conjunto de réplicas até que os membros escolham um novo primário.

Exemplo

Dado um conjunto de réplicas de três membros em que cada membro tem um voto, o conjunto pode eleger uma primária se pelo menos dois membros puderem se conectar uns aos outros. Se você reinicializar os dois secundários de uma só vez, o primário desaparecerá e se tornará um secundário. Até que pelo menos outro secundário esteja disponível, ou seja, pelo menos um dos secundários reiniciados também fique disponível, o conjunto não tem primário e não pode eleger um novo primário.

Para obter mais informações sobre votos, consulte Eleições do conjunto de réplicas. Para obter informações relacionadas sobre erros de conexão, consulte O tempo de keepalive TCP afeta as implementações do MongoDB?.

Verificar o tamanho do Oplog

Um oplog maior pode dar a um conjunto de réplicas uma maior tolerância a atrasos e tornar o conjunto mais resiliente.

Para verificar o tamanho do oplog de um determinado membro do conjunto de réplica, conecte ao membro no mongosh e execute o método rs.printReplicationInfo().

A saída exibe o tamanho do oplog e os intervalos de datas das operações contidas no oplog. No exemplo a seguir, o oplog é de cerca de 10 MB e é capaz de ajustar cerca de 26 horas (94400 segundos) de operações:

configured oplog size:   10.10546875MB
log length start to end: 94400 (26.22hrs)
oplog first event time:  Mon Mar 19 2012 13:50:38 GMT-0400 (EDT)
oplog last event time:   Wed Oct 03 2012 14:59:10 GMT-0400 (EDT)
now:                     Wed Oct 03 2012 15:00:21 GMT-0400 (EDT)

O oplog deve ser longo o suficiente para manter todas as transações pelo maior tempo de inatividade esperado em um secundário. [1] No mínimo, um oplog deve ser capaz de manter no mínimo 24 horas de operações; no entanto, muitos usuários preferem ter 72 horas ou até mesmo uma semana de trabalho de operações.

Para obter mais informações sobre como o tamanho do oplog afeta as operações, consulte:

Observação

Normalmente, você deseja que o oplog tenha o mesmo tamanho em todos os membros. Se você redimensionar o oplog, redimensione-o em todos os membros.

Para alterar o tamanho do oplog, consulte o tutorial Alterar o tamanho do oplog de membros do conjunto de réplicas autogerenciado .

[1]	O oplog pode ultrapassar seu limite de tamanho configurado para evitar a exclusão do `majority commit point`.

Voltar

Algoritmo de Seleção do Servidor

Banco de dados local.