Estratégias de Monitoramento e Backup no MongoDB

Entender o que realmente precisa ser observado em uma implantação MongoDB em execução antes que vire um incidente, e como tirar os dados com segurança quando algo dá errado mesmo assim. O livro trata o monitoramento como pré-requisito, não como algo para depois: "Antes de implantar, é importante configurar algum tipo de monitoramento. O monitoramento deveria permitir acompanhar o que seu servidor está fazendo e alertar você se algo der errado." Os backups recebem o mesmo enquadramento do outro lado da mesma moeda: "Backups são uma boa proteção contra a maioria dos tipos de falha, e muito pouco não pode ser resolvido restaurando um backup limpo", mas só se você realmente tiver praticado a restauração, e não apenas o dump.

• Rodar mongostat durante um incidente ao vivo para ter uma visão de uma linha por segundo de ops/s, page faults, profundidade de fila e conexões de toda a implantação, sem abrir um dashboard.
• Rodar mongotop para descobrir qual coleção específica está consumindo tempo de leitura/escrita agora, quando o mongostat diz que o servidor está ocupado, mas não com o quê.
• Ler os campos extra_info.page_faults e wiredTiger.concurrentTransactions do db.serverStatus() para obter os mesmos números que um dashboard mostraria, de forma programável e sem nenhum agente de terceiros instalado.
• Acompanhar gráficos de atraso de replicação para pegar um secundário ficando para trás em silêncio (o sinal de alerta padrão de um sistema sobrecarregado, de um índice _id ausente ou de um problema de rede) antes que ele fique desatualizado e precise de uma ressincronização completa.
• Escolher um método de backup pela forma da implantação: mongodump/mongorestore para um único banco ou coleção, snapshots de sistema de arquivos/volume para um membro inteiro de replica set de forma rápida e consistente, e o serviço de backup gerenciado de um provedor (Atlas, ou Cloud/Ops Manager para autogerenciados) quando o cluster inteiro, incluindo os config servers de um cluster shardeado, precisa ser coberto em um agendamento.

A escada de ferramentas: mongostat, mongotop, serverStatus e um sistema de monitoramento de verdade

O livro apresenta o monitoramento como três perguntas que vale acompanhar continuamente: "Como acompanhar o uso de memória do MongoDB. Como acompanhar métricas de desempenho da aplicação. Como diagnosticar problemas de replicação." Ele demonstra as métricas usando gráficos do MongoDB Ops Manager, observando que "as capacidades de monitoramento do MongoDB Atlas (o serviço de banco de dados em nuvem do MongoDB) são muito parecidas", e cita também uma opção gratuita: o serviço de monitoramento gratuito do MongoDB, que "guarda os dados de monitoramento por 24 horas depois de enviados e fornece estatísticas de granularidade grossa sobre tempos de execução das operações, uso de memória, uso de CPU e contagem de operações." O conselho final do capítulo é direto: "Se você não quiser usar o Ops Manager, o Atlas ou o serviço de monitoramento gratuito do MongoDB, por favor use algum tipo de monitoramento."

Por baixo de qualquer dashboard, as mesmas três primitivas fornecem os números: mongostat (um resumo por segundo do servidor inteiro no estilo vmstat: ops/s por tipo, page faults, leituras/escritas em fila, conexões, atraso de replicação), mongotop (a mesma ideia restrita ao tempo de leitura/escrita por coleção, útil para descobrir qual coleção está quente) e db.serverStatus() (um único snapshot JSON de tudo, incluindo campos que o livro cita diretamente: db.adminCommand({"serverStatus": 1})["extra_info"] retornando { "note" : "fields vary by platform", "page_faults" : 50 }, uma contagem acumulada de page faults desde que o processo iniciou).

Memória e page faults: a métrica que mais importa

O raciocínio do livro aqui é a base de todo o resto do capítulo: "Acessar dados na memória é rápido, e acessar dados no disco é lento... normalmente o MongoDB esgota a memória antes de qualquer outro recurso... O uso de memória do MongoDB é uma das estatísticas mais importantes para acompanhar." Ele divide a memória do servidor em três valores reportados: residente (dados de fato carregados na RAM agora), virtual (a abstração de espaço de endereçamento do sistema operacional, "tipicamente o dobro do tamanho da memória mapeada") e mapeada (relevante só para o storage engine MMAP anterior ao 4.0: "agora que o MongoDB usa o storage engine WiredTiger, você deveria ver uso zero de memória mapeada"). A memória residente é a que responde à pergunta real: "Se seus dados cabem inteiramente na memória, a memória residente deveria ser aproximadamente o tamanho dos seus dados."

Page faults são o indicador antecedente de pressão de memória: um page fault significa que "os dados que o MongoDB procura não estão na RAM" e precisam ser copiados do disco, o que é ordens de grandeza mais lento. A orientação do livro sobre como interpretar o número é deliberadamente não absoluta ("se o disco... aguenta essa quantidade de faults e a aplicação aguenta o atraso dos seeks de disco, não há problema particular em ter tantos faults"), mas ele aponta que a carga de disco não é linear: "quando um disco começa a ficar sobrecarregado, cada operação precisa esperar na fila por um tempo cada vez maior, criando uma reação em cadeia." A versão acionável disso: "Acompanhe seus números de page faults ao longo do tempo. Se sua aplicação se comporta bem com uma certa quantidade de page faults, você tem uma linha de base de quantos page faults o sistema aguenta. Se os page faults começarem a subir e o desempenho piorar, você tem um limite para alertar." Em outras palavras, page faults não são uma métrica com uma linha vermelha universal: são uma métrica para a qual você estabelece uma linha de base para a sua carga e alerta sobre desvios.

O conceito por baixo de tudo isso é o working set, "os dados e índices que sua aplicação usa", que o livro ordena por quão desejável é cada cenário: o dataset inteiro na memória (o melhor, muitas vezes inviável), o working set na memória (o alvo comum: "geralmente há um conjunto central de dados... que cobre 90% das requisições"), até nenhum subconjunto útil na memória ("vai ser lento"). Dimensionar um working set é um exercício de medição, não um chute: acompanhe quantos dados são criados e quanto deles continua "quente"; o exemplo resolvido do livro coloca uma taxa de escrita de 2 GB/semana com um padrão de acesso de um mês em cerca de 3,2 GB de working set, "mais uma margem para os índices."

Atraso de replicação e duração do oplog

Uma vez entendida a memória, a saúde da replicação é o próximo nível. O atraso é definido com precisão: "Ele é calculado subtraindo o horário da última operação aplicada em um secundário do horário da última operação no primário." Um secundário saudável mostra atraso "basicamente 0 o tempo todo", na ordem de milissegundos. As duas formas de falha que o livro descreve valem ser distinguidas, porque pedem respostas diferentes:

• Replicação travada: o atraso cresce exatamente um segundo por segundo, "o caso mais extremo", normalmente causado por um problema de rede ou por um índice _id ausente (que o livro aponta como obrigatório para a replicação funcionar). A correção que ele prescreve é específica: tire o secundário do conjunto, inicie-o isolado e crie o índice ("como índice único") antes de colocá-lo de volta.
• Sobrecarga gradual: um secundário fica para trás devagar sob carga contínua, sem a inclinação característica de um segundo por segundo, porque "alguma replicação ainda está acontecendo." É um problema de capacidade, não de corrupção ou de configuração, e a correção é reduzir a carga nesse membro, não repará-lo.

O livro também alerta para uma leitura: "picos repentinos de atraso de replicação" em um sistema com pouquíssima escrita podem ser atraso fantasma, um artefato de amostragem por medir o timestamp do secundário logo antes da próxima escrita no primário, e não atraso real. Não persiga um pico que some quando a taxa de escrita sobe.

A duração do oplog (quanto tempo de relógio o oplog de um membro cobre antes de começar a sobrescrever entradas antigas) é a margem de segurança de quanto tempo um secundário pode ficar fora do ar ou atrasado antes de ficar desatualizado e precisar de uma ressincronização completa. A regra prática do livro: "Todo membro que possa virar primário deveria ter um oplog de mais de um dia... Em geral, os oplogs deveriam ser tão longos quanto o espaço em disco que você pode pagar", e a troca é realmente de um lado só, já que "eles basicamente não ocupam memória."

O sucessor da porcentagem de lock: o sistema de tickets

Dashboards antigos de monitoramento do MongoDB acompanhavam uma métrica de "porcentagem de lock" sob o modelo de lock global do storage engine MMAP. O WiredTiger substituiu isso por concorrência em nível de documento mais um sistema de tickets: "ele emite tickets para operações de leitura e escrita (128 de cada, por padrão), e a partir daí novas operações de leitura ou escrita entram em fila." O livro dá os campos exatos a observar para esgotamento (wiredTiger.concurrentTransactions.read.available e wiredTiger.concurrentTransactions.write.available na saída do serverStatus): chegar a zero significa que novas operações daquele tipo agora estão entrando em fila. Essa profundidade de fila é o equivalente moderno do antigo alarme de porcentagem de lock: "o tamanho da fila deveria ser baixo. Uma fila grande e sempre presente é sinal de que o mongod não está dando conta da carga."

Abordagem de backup 1: dump lógico (mongodump/mongorestore)

O mongodump lê todo documento pela camada de consulta e o grava como BSON, organizado em arquivos por banco e por coleção. É a opção mais flexível ("uma boa forma de fazer backup de bancos individuais, coleções e até subconjuntos de coleções"), mas o livro é explícito sobre os custos em relação aos outros métodos: "é mais lento (tanto para fazer o backup quanto para restaurar a partir dele) e tem alguns problemas com replica sets." O problema central é que um mongodump simples não é de um ponto no tempo: ele lê o servidor enquanto as escritas continuam acontecendo, então um dump demorado pode capturar uma mistura inconsistente de estado antes/depois; "você pode acabar em uma situação em que o usuário A começa um backup que faz o mongodump despejar o banco A, mas enquanto isso acontece o usuário B apaga o A." A correção do livro é a flag --oplog em um mongod com replica set, que registra toda operação que acontece durante o dump para que mongorestore --oplogReplay possa reexecutá-las e chegar a um snapshot realmente consistente.

Duas restrições rígidas valem destaque, porque é fácil violá-las por acidente. Primeiro: nunca combine fsyncLock() com mongodump; o aviso do próprio livro é direto: "o mongodump pode travar para sempre se o banco estiver com lock." Segundo, índices únicos complicam um ciclo de dump/restore, porque "índices únicos exigem que os dados não mudem, durante a cópia, de formas que violariam a restrição do índice único": um dump/restore simples (sem --oplog) de uma coleção com um índice único (além do _id) pode restaurar dados que violam momentaneamente a própria restrição no meio da carga.

Abordagem de backup 2: snapshot de sistema de arquivos/volume

A outra família de técnicas faz backup do disco, não dos documentos: o LVM (ou um snapshot equivalente de armazenamento em bloco na nuvem) captura uma imagem copy-on-write, de um ponto no tempo, do volume em que estão os arquivos de dados do MongoDB. O resumo do livro sobre a troca: "Esses métodos terminam rápido e funcionam de forma confiável, mas exigem configuração adicional do sistema fora do MongoDB." A consistência é o porém: "o banco precisa estar com lock e todas as escritas precisam ser suspensas durante o processo de backup", o que se consegue com db.fsyncLock() antes do snapshot e db.fsyncUnlock() logo depois, já que "a primeira ação do mongod" em uma sincronização inicial nova "é apagar tudo" se ele for apontado para o diretório de dados errado, e um snapshot tirado no meio de uma escrita não tem garantia de consistência. Como os arquivos de dados do WiredTiger "refletem um estado consistente a partir do último checkpoint" (os checkpoints acontecem a cada minuto), um snapshot não precisa de coordenação em nível de aplicação além do lock de fsync: o próprio checkpointing do storage engine faz o resto.

A forma operacional deste método (lvcreate --snapshot, montar o snapshot, copiá-lo ou passá-lo por dd | gzip para outro lugar) é rápida o suficiente para que o livro recomende rodá-lo contra um secundário, não contra o primário, exatamente pelo mesmo motivo pelo qual recomenda rodar o mongodump fora do primário: "fazer um backup pode sobrecarregar um sistema: em geral exige ler todos os seus dados para a memória", e essa carga pertence a qualquer lugar menos ao nó que atende as escritas ao vivo.

Escolhendo entre eles, e o quadro no nível do cluster

Para um único servidor ou um replica set, snapshots de sistema de arquivos/volume e cópias do diretório de dados são o padrão preferido do livro ("um snapshot de sistema de arquivos ou uma cópia dos arquivos de dados é recomendado"), com o mongodump posicionado como alternativa para backups mais granulares (um único banco/coleção). Para um cluster shardeado, não há forma de obter um snapshot perfeitamente consistente do cluster inteiro enquanto ele está ativo ("clusters shardeados são impossíveis de 'perfeitamente' copiar enquanto ativos"), então a abordagem prática é fazer backup das peças (o replica set de cada shard, mais os config servers) com o balancer parado, ou se apoiar em um serviço de backup gerenciado (Cloud Manager, Ops Manager ou Atlas) que automatiza exatamente essa coordenação entre várias peças.

Livro vs. hoje

O Atlas, não o Ops Manager, agora é a recomendação padrão para a maioria dos usuários. O livro já observava que o monitoramento do Atlas "é muito parecido" com os gráficos do Ops Manager, mas a documentação atual do MongoDB vai além: o Atlas é posicionado como a superfície principal e ativamente desenvolvida de monitoramento e backup (com Performance Advisor, Real-Time Performance Panel, Query Profiler e alertas embutidos), enquanto o Ops Manager continua sendo o caminho suportado especificamente para implantações autogerenciadas e on-premises que não podem ir para um serviço de nuvem gerenciado. O enquadramento deste capítulo com foco em hospedagem própria (o Ops Manager como exemplo principal, o Atlas como "parecido") efetivamente se inverteu.

O Cloud Manager, a outra ferramenta citada no livro, está sendo desativado para versões antigas do MongoDB. A documentação atual do MongoDB afirma que o Cloud Manager deixou de suportar automação, backup e monitoramento para o MongoDB 3.6 e 4.0 depois de 30 de agosto de 2024, e direciona os usuários para o Atlas (para implantações em nuvem) ou o Ops Manager (para on-premises). O Cloud Manager não era um conceito da época do livro descrito como legado; agora ele é explicitamente apresentado como a ferramenta da qual migrar.

A terminologia de backup do próprio Atlas se consolidou em torno de "Cloud Backups". O que o livro chama de "continuous backups" e "cloud provider snapshots", duas opções do Atlas Cloud, agora está unificado no recurso Cloud Backup do Atlas, que tira snapshots usando a funcionalidade nativa do provedor de nuvem por baixo (AWS, Azure ou GCP) com redundância entre zonas de disponibilidade embutida, e pode ainda replicar snapshots e oplogs entre regiões para recuperação de desastres.

mongodump --oplog em um cluster shardeado é um "não" mais firme do que o livro dá a entender. O livro já avisa que a partir do MongoDB 4.2 "você não pode usar nem o mongodump nem o mongorestore como estratégia de backup de um cluster shardeado", por motivos de atomicidade. A documentação atual torna isso mais preciso especificamente para --oplog: ele "não tem efeito ao rodar o mongodump em uma instância mongos"; a flag não degrada com elegância, ela simplesmente não faz nada em silêncio, então um script que presume consistência de ponto no tempo para um dump shardeado está errado mesmo antes da ressalva de atomicidade do 4.2. Suspender o balancer, pausar transações entre shards e pausar DDL agora são pré-requisitos explícitos documentados para qualquer mongodump rodado contra um cluster shardeado.

• mongostat/mongotop/serverStatus não custam nada para usar, mas exigem um humano olhando; Atlas/Ops Manager custam tempo de configuração, mas alertam sozinhos. Os comandos brutos estão sempre disponíveis e não precisam de agente instalado, o que os torna ideais durante um incidente ativo. Eles não acordam ninguém às 3 da manhã; isso exige a camada de dashboards e alertas que o livro passa a maior parte do capítulo demonstrando com os gráficos do Ops Manager.
• Memória residente e page faults são sinais baratos sem limite universal. Eles dizem muito sobre uma carga específica depois de estabelecida a linha de base, mas o livro é explícito ao dizer que uma dada taxa de faults é tranquila ou catastrófica dependendo inteiramente da capacidade do seu disco e da tolerância de latência da sua aplicação: o número só é acionável em relação ao seu próprio histórico, não como valor absoluto.
• mongodump/mongorestore trocam velocidade e risco de corretude por granularidade de backup. São o único método que permite fazer backup (ou restaurar) seletivamente um único banco ou coleção, e funcionam sem nenhuma configuração no nível do sistema, mas são mais lentos que um snapshot de sistema de arquivos, precisam da flag --oplog para consistência de ponto no tempo em um replica set e não são suportados para consistência de um cluster shardeado inteiro.
• Snapshots de sistema de arquivos/volume trocam flexibilidade de backup por velocidade e simplicidade. São rápidos, consistentes com o storage engine por construção (graças aos checkpoints do WiredTiger mais o fsyncLock) e não exigem leitura dos dados pela camada de consulta, mas precisam de ferramentas no nível do sistema (LVM ou um recurso de snapshot de armazenamento em bloco na nuvem) fora do controle do MongoDB, e fazem backup de tudo no volume, não de um subconjunto escolhido.
• Um oplog maior compra a prevenção de ressincronizações por um custo de disco fixo e baixo. A orientação do livro de dimensionar para dois a três dias é uma troca direta: o armazenamento do oplog "basicamente não ocupa memória", então errar para um oplog mais longo é um seguro quase gratuito contra um secundário atrasado ficar desatualizado durante uma manutenção planejada ou uma queda não planejada.
• Serviços de backup gerenciados (Atlas Cloud Backup, Cloud Manager, Ops Manager) trocam controle operacional por consistência coordenada no cluster inteiro. Scripts próprios de mongodump/snapshot dão controle total sobre exatamente o que é capturado e quando, mas coordenar isso corretamente entre todos os shards e os config servers de um cluster shardeado é exatamente o problema de várias peças que um serviço de backup gerenciado existe para automatizar.