A configuração inadequada dos parâmetros de oplog em uma instância do ApsaraDB for MongoDB pode causar problemas como replicação anormal entre primário e secundário, além de impedir restaurações point-in-time. Saiba como configurar os parâmetros de oplog e entenda os riscos associados.
Visão geral
Nas instâncias de replica set do ApsaraDB for MongoDB, a replicação de dados ocorre por meio do oplog (operations log), uma capped collection chamada local.oplog.rs que registra todas as operações de modificação de documentos. Principais características:
Operações de escrita no nó primário geram entradas no oplog. Os nós secundários replicam e reaplicam essas entradas de forma assíncrona para manter a sincronização.
Operações que não modificam documentos ou que falham não geram entradas no oplog.
As entradas do oplog são idênticas em todos os membros do replica set. A aplicação de uma entrada não altera a entrada em si.
Toda operação do oplog é idempotente — o resultado é o mesmo, seja aplicada uma ou várias vezes.
As entradas do oplog seguem uma ordem temporal. Cada uma possui um campo de timestamp exclusivo (ts) que combina um timestamp UNIX e um contador incremental, garantindo uma ordenação rigorosa.
A
oplog windowé o intervalo de tempo entre a entrada mais antiga e a mais recente do oplog. Um nó secundário só consegue sincronizar se sua entrada inicial necessária estiver dentro da janela de oplog da fonte de replicação.Nós reiniciados ou recém-adicionados também dependem das entradas do oplog para ingressar no replica set. Se a entrada necessária estiver ausente, o nó entra em um estado anormal de RECOVERING com o erro
too stale to catch up.
Tamanho do oplog
No ApsaraDB for MongoDB, o tamanho padrão do oplog corresponde a 10% do espaço total em disco. Por exemplo, um disco de 500 GB resulta em um oplog de 50 GB. O oplog é dimensionado automaticamente quando você aumenta o espaço em disco.
Para ajustar o tamanho do oplog, modifique o parâmetro replication.oplogSizeMB no console. A alteração entra em vigor imediatamente, sem necessidade de reinicialização. Definir parâmetros de banco de dados.
Para verificar o tamanho da tabela do oplog:
Verifique a métrica Disk Space Usage na página de monitoramento do console. Monitoramento de nós (anteriormente Monitoramento básico).
-
Conecte-se via mongo shell ou mongosh e execute o seguinte comando.
rs.printReplicationInfo()Exemplo de saída:
configured oplog size: 192MB log length start to end: 65422secs (18.17hrs) oplog first event time: Mon Jun 23 2014 17:47:18 GMT-0400 (EDT) oplog last event time: Tue Jun 24 2014 11:57:40 GMT-0400 (EDT) now: Thu Jun 26 2014 14:24:39 GMT-0400 (EDT)Isso indica um oplog de 192 MB com uma janela de oplog de 18 horas.
Período mínimo de retenção do oplog
O MongoDB 4.4 introduziu o parâmetro storage.oplogMinRetentionHours para controlar o período mínimo de retenção do oplog e garantir uma janela de oplog suficiente.
O valor padrão é 0 (sem retenção mínima; a limpeza é controlada pelo tamanho do oplog). Quando definido, a limpeza do oplog ocorre apenas quando ambas as condições são atendidas:
O uso do oplog excede o valor configurado em
oplogSizeMB.Os timestamps das entradas são anteriores ao período mínimo de retenção do oplog.
Antes que o oplog atinja oplogSizeMB (por exemplo, em uma nova instância), a janela real do oplog pode exceder o período mínimo de retenção configurado, e o tamanho é limitado apenas por oplogSizeMB. Após atingir oplogSizeMB, o período de retenção passa a governar a limpeza. Altas taxas de escrita podem fazer com que o oplog cresça muito além de oplogSizeMB.
Para ajustar o período de retenção, modifique storage.oplogMinRetentionHours no console. A alteração entra em vigor imediatamente, sem necessidade de reinicialização. Definir parâmetros de banco de dados.
Para visualizar o período de retenção, verifique a métrica Oplog retention duration na página de monitoramento do console. Monitoramento de nós (anteriormente Monitoramento básico).
Backup de logs do ApsaraDB for MongoDB
O backup de logs das instâncias do ApsaraDB for MongoDB utiliza o oplog. Um processo dedicado busca continuamente as entradas mais recentes do oplog e as transmite para o Object Storage Service (OSS) como arquivos de backup de logs. Durante restaurações point-in-time, esses arquivos reexecutam o oplog.
Em alguns casos, lacunas podem aparecer nos backups de logs, impedindo restaurações point-in-time. Riscos.
A lacuna de backup de logs descrita aqui difere da lacuna de oplog do MongoDB.
Melhores práticas
Configurar tamanho ou retenção do oplog
O tamanho padrão do oplog é suficiente para a maioria das cargas de trabalho. Considere aumentá-lo nestes cenários:
-
Atualizações em lote frequentes
Cada atualização em lote gera múltiplas operações individuais, produzindo muitas entradas no oplog.
-
Inserções e exclusões frequentes
O uso de disco permanece estável, mas o oplog acumula entradas tanto para operações de inserção quanto de exclusão.
-
Numerosas atualizações in-place nos mesmos documentos
Atualizações que não aumentam o tamanho do documento geram muitas entradas no oplog sem alterar significativamente o uso de disco.
Considere reduzir o tamanho do oplog para:
Cargas de trabalho com muita leitura e pouca escrita.
Armazenamento de dados frios.
Mantenha a janela do oplog em 24 horas ou mais. Para cenários de sincronização inicial, a janela deve cobrir o tempo necessário para copiar todos os dados, o que depende do volume de dados, da quantidade de coleções e das especificações da instância. Nesses casos, uma janela de oplog maior pode ser necessária.
Monitorar atraso de nós secundários e configurar alertas
Se o atraso de replicação exceder a janela do oplog, o nó secundário entrará em um estado de erro irrecuperável. Monitore o atraso de replicação e envie um ticket prontamente se o atraso aumentar continuamente.
Causas comuns:
Latência de rede, perda de pacotes ou interrupções.
O throughput de disco do nó secundário atua como gargalo.
Carga intensa de escrita combinada com write concern de
{w:1}.Defeitos de kernel que bloqueiam a replicação primário-secundário no nó secundário.
Outros motivos não listados.
Para verificar o atraso de replicação:
Visualize a métrica Primary/Secondary Replication Latency na página de monitoramento do console. Monitoramento de nós (anteriormente Monitoramento básico).
-
Conecte-se via mongo shell ou mongosh e execute:
rs.printSecondaryReplicationInfo()Exemplo de saída:
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 primaryAmbos os nós secundários apresentam atraso de replicação zero.
Crie um alerta no CloudMonitor para a métrica Replication Latency usando o recurso Alarm Rules. Defina o limiar para 10 segundos ou mais. Definir uma regra de alerta baseada em limiar.
Riscos
Duas causas principais criam lacunas no backup de logs:
Versões do MongoDB anteriores à 3.4
O MongoDB 3.4 introduziu escritas no-op periódicas para suportar o parâmetro de preferência de leitura maxStalenessSeconds (SERVER-23892). Essas escritas no-op avançam o oplog durante períodos ociosos, permitindo a medição precisa do atraso para nós secundários.
Em versões anteriores à 3.4, o oplog para de avançar durante períodos ociosos. O processo de backup de logs não consegue buscar novos dados, criando uma lacuna de backup que impede restaurações point-in-time.
Alta taxa de escrita e janela curta de oplog
Dados de instâncias do ApsaraDB for MongoDB mostram que, quando a taxa de geração de oplog atinge aproximadamente 125 GB/h a 165 GB/h, há grande probabilidade de o processo de backup de logs ficar atrasado, criando uma lacuna de backup.
Estime a taxa de geração dividindo o tamanho do oplog pela janela do oplog. Por exemplo, um oplog de 20 GB com uma janela de 0,06 h resulta em aproximadamente 333,3 GB/h.
Cenários típicos:
Sincronização de dados com DTS, mongoShake ou ferramentas similares.
Grandes lotes de operações INSERT ou UPDATE em curto período.
Preenchimento de dados (importação em massa rápida).
Testes de estresse.
Para evitar lacunas de backup causadas por altas taxas de escrita:
Aplique limitação de taxa nas ferramentas de sincronização ajustando a concorrência ou o tamanho do lote.
Use write concern de
{w:"majority"}em vez de{w:1}.
Para cargas de trabalho com taxas de geração de oplog inerentemente altas:
Utilize um cluster com sharding ou adicione shards para distribuir a taxa de geração de oplog.
Aumente o tamanho do oplog ou o período mínimo de retenção para dar ao processo de backup mais buffer para recuperação durante períodos de menor tráfego.