A configuração incorreta de parâmetros do 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 do oplog e entenda os riscos associados.
Visão geral
Em instâncias de conjunto de réplicas 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 conjunto de réplicas. 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 ordenação rigorosa.
A
oplog windowcorresponde ao intervalo de tempo entre a entrada mais antiga e a mais recente do oplog. Um nó secundário só consegue se sincronizar se sua entrada inicial necessária estiver dentro da janela do oplog da fonte de replicação.Nós reiniciados ou recém-adicionados também dependem das entradas do oplog para ingressar no conjunto de réplicas. Caso a entrada necessária esteja 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 é de 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. Set database parameters.
Para verificar o tamanho da tabela do oplog:
Verifique a métrica Disk Usage na página de monitoramento do console. Node Monitoring (formerly Basic Monitoring).
-
Conecte-se via mongo shell ou mongosh e execute o seguinte comando.
rs.printReplicationInfo()Saída de exemplo:
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 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 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 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. Set database parameters.
Para visualizar o período de retenção, verifique a métrica Oplog retention duration na página de monitoramento do console. Node Monitoring (formerly Basic Monitoring).
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 surgir nos backups de logs, impedindo restaurações point-in-time. Risks.
A lacuna de backup de logs descrita aqui difere da oplog hole 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.
-
Muitas 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 initial sync, 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 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. Node Monitoring (formerly Basic Monitoring).
-
Conecte-se via mongo shell ou mongosh e execute:
rs.printSecondaryReplicationInfo()Saída de exemplo:
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 Cloud Monitor para a métrica Replication Latency usando o recurso Alarm Rules. Defina o limiar para 10 segundos ou mais. Set a threshold-based alert rule.
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 medições precisas de 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 que impede restaurações point-in-time.
Alta taxa de escrita e janela curta do oplog
Dados de instâncias do ApsaraDB for MongoDB mostram que, quando a taxa de geração do oplog atinge aproximadamente 125 GB/h a 165 GB/h, há grande probabilidade de o processo de backup de logs ficar para trás, criando uma lacuna.
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 inicial 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 fragmentado ou adicione shards para distribuir a taxa de geração do 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.