Solucionar problemas de conjuntos de réplicas
Nesta página
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étodors.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 valormembers[n].secondaryDelaySecs
.Observação
O método
rs.status()
é um invólucro em torno do comandoreplSetGetStatus
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 etraceroute
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
ouvmstat
.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
Os administradores podem limitar a taxa na qual o primário aplica suas gravações com o objetivo de manter o atraso majority
committed
abaixo de um valor máximo 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 valorflowControl.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 textoapplied 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çãom1.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 dem2.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
em1.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 dom3.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 . |