Solucionar problemas de atraso de replicação

Latência de rede

O atraso de replicação pode aumentar quando os nós do cluster não podem se comunicar de forma confiável uns com os outros.

Verifique as rotas de rede entre os membros do seu conjunto de réplicas para garantir que não haja perda de pacote ou problemas de roteamento de rede.

Use ferramentas, incluindo para testar a latência entre ping membros traceroute definidos e para expor o roteamento de pacotes entre pontos de extremidade da rede.

Como alternativa, execute e examine replSetGetStatus o pingMs campo . Isso retorna a latência de rede atual em milissegundos entre os nós primários e secundários.

Esgotação de recursos secundários

Os nós secundários podem enfrentar contenção de recursos quando não conseguem lidar com eficiência com as operações de leitura recebidas do primário. Isso pode causar problemas de memória, como contenção de cache. Quando o cache atinge limites críticos, o servidor usa threads de aplicação para remover páginas, o que reduz o número de threads disponíveis para gerenciar a replicação.

Para ver se o servidor redireciona threads de aplicação para tarefas de despejo, execute o seguinte comando em sua shell mongosh:

db.serverStatus().wiredTiger.cache['pages evicted by application threads']

• Se Resultado 0 =: nenhum thread de aplicação é pausado para remoção.

• Se Resultado > 0 (e aumentando): o banco de dados está sob pressão de cache. As queries de entrada devem remover dados armazenados em cache antes de serem executadas, o que pode aumentar o atraso de replicação.

Os usuários do Atlas também podem monitorar as métricas WiredTiger Cache Activity e Page Faults para investigar problemas relacionados ao cache.

Para ver possíveis estratégias para corrigir esse problema, consulte Dimensionar seus recursos.

Problemas relacionados ao disco

Se um nó secundário não conseguir liberar dados sujos para o disco com rapidez suficiente, ele ficará atrás do primário. Esse surgimento ocorre quando o volume de gravações do primário excede a velocidade de gravação do disco do secundário.

Problemas relacionados a disco prevalecem 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.

Para avaliar o status do disco, use ferramentas no nível do sistema, como iostat ou vmstat.

Os usuários do Atlas podem acessar as métricas do Atlas , como Disk IOPS e,Disk Space Used para investigar problemas de disco.

Algumas causas comuns de problemas de disco incluem:

• Subprovisionamento: o secundário tem discos mais lentos ou IOPS mais baixo do que o principal.

• Sobrecarga de virtualização: em ambientes compartilhados, outras máquinas virtuais podem saturar o controlador de disco físico.

Algumas possíveis soluções para problemas de disco incluem:

• Aumentando o IOPS provisionado

• Atualizando para armazenamento NVMe

• Atualizando para uma camada do cluster Atlas superior . Para mais informações, consulte Dimensionamento do Atlas cluster e Seleção de Nível.

Operações de longa duração

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 de banco de dados para identificar queries lentas ou operações de longa duração que se correlacionam com o atraso observado.

Carga de gravação excessiva

As operações de escrita em massa podem exceder a capacidade dos conjuntos de réplicas de replicar em tempo hábil, causando atraso de replicação.

As subseções a seguir oferecem possíveis soluções para esse problema:

db.collName.deleteMany({createdDate: {$gte: new Date("2018-12-01"), $lt: new Date("2019-01-01")}});
db.collName.deleteMany({createdDate: {$gte: new Date("2018-11-01"), $lt: new Date("2018-12-01")}});
db.collName.deleteMany({createdDate: {$gte: new Date("2018-10-01"), $lt: new Date("2018-11-01")}});

db.collection.createIndex({ status: 1 });

db.collection.deleteMany({ status: "inactive" });

Tamanho da janela do oplog

Se a oplog window for muito pequena para a quantidade de dados que está sincronizando, você poderá enfrentar um atraso de replicação. Um oplog maior pode dar a um conjunto de réplicas uma maior tolerância a atrasos.

Para verificar o tamanho do oplog e os intervalos de datas de suas operações para um determinado membro do conjunto de réplica, conecte ao membro no mongosh e execute o rs.printReplicationInfo() método. 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 alterar o tamanho do oplog, consulte o tutorial Alterar o tamanho do oplog de membros do conjunto de réplicas autogerenciado .