Gerenciando e Liberando Espaço em Disco em Implantações MongoDB

Problemas de espaço em disco no MongoDB geralmente aparecem de duas formas: o sistema de arquivos está quase cheio, ou o MongoDB parece grande mesmo depois de você excluir dados. Esse segundo caso surpreende muitas equipes porque o WiredTiger pode reutilizar espaço liberado internamente sem devolvê-lo imediatamente ao sistema operacional.

Seu objetivo é diferenciar entre crescimento real, espaço livre interno reutilizável, índices superdimensionados e fragmentação que precisa de uma janela de manutenção.

Verifique o Uso de Disco no Nível do Host

Comece pelo sistema de arquivos que contém o dbPath do MongoDB. O MongoDB não consegue continuar escrevendo com segurança se esse volume ficar cheio.

df -h /var/lib/mongodb

Verifique também quais diretórios estão crescendo:

du -sh /var/lib/mongodb/* | sort -h

Use seu dbPath real; /var/lib/mongodb é comum em pacotes Linux, mas não universal.

Verifique as Métricas de Armazenamento do MongoDB

Dentro do mongosh, compare o tamanho lógico dos dados com o tamanho de armazenamento alocado.

use myDatabase
db.stats()

Campos úteis incluem:

• dataSize: Tamanho lógico dos dados dos documentos.
• storageSize: Espaço alocado para dados da coleção.
• indexSize: Espaço usado pelos índices.

Para uma coleção específica:

db.orders.stats({ scale: 1024 * 1024 })

Observe size, storageSize e totalIndexSize. Se storageSize for muito maior que size, a coleção pode ter espaço interno reutilizável de atualizações e exclusões. Se totalIndexSize for grande, os índices podem ser a maneira mais rápida de reduzir o uso de disco.

Causas Comuns do Crescimento de Disco no MongoDB

Alta rotatividade de exclusões e atualizações pode deixar espaço livre interno dentro dos arquivos WiredTiger. O MongoDB geralmente reutiliza esse espaço para futuras gravações, mas o sistema operacional ainda pode mostrar os arquivos como grandes.

Índices também podem consumir uma grande parte do disco. Índices compostos, de texto, curinga e duplicados se acumulam rapidamente.

Lacunas de retenção são outra causa comum. Coleções de log, sessão, evento e auditoria crescem para sempre, a menos que você arquive ou expire documentos antigos.

Maneiras Seguras de Reduzir o Crescimento Futuro

A melhor correção de disco geralmente é evitar o crescimento ilimitado.

Para dados baseados em tempo, crie um índice TTL:

db.logEvents.createIndex(
  { createdAt: 1 },
  { expireAfterSeconds: 86400 }
)

A exclusão TTL é gerenciada por um monitor em segundo plano e não é instantânea ao segundo. Ainda é uma boa opção para logs, sessões e eventos temporários onde o tempo exato de exclusão não é crítico.

Revise os índices antes de descartar qualquer coisa:

db.orders.getIndexes()
db.orders.aggregate([{ $indexStats: {} }])

$indexStats pode mostrar se um índice foi usado desde que o processo foi iniciado. Trate isso como uma pista, não como prova. Um índice de relatório mensal pode parecer não utilizado em uma semana tranquila.

Descarte um índice confirmado como não utilizado pelo nome:

db.orders.dropIndex('customerId_1_createdAt_-1')

Recupere Espaço de Arquivos Existentes

Excluir documentos geralmente não reduz os arquivos WiredTiger no disco. Para devolver espaço ao sistema de arquivos, você precisa de uma estratégia de reescrita ou compactação.

Use compact com Cuidado

compact pode reescrever dados de coleção e índice para reduzir o uso de disco. É intensivo em recursos e pode bloquear operações na coleção afetada, dependendo da sua versão do MongoDB e implantação.

db.runCommand({ compact: 'orders' })

Execute durante uma janela de manutenção, teste primeiro e leia a documentação para sua versão exata do MongoDB. Em conjuntos de réplicas, muitas equipes compactam um secundário de cada vez, deixam-no alcançar e depois trocam ou rotacionam membros conforme necessário.

Despejo e Restauração para Fragmentação Severa

Para dados severamente fragmentados, um despejo e restauração reconstrói os arquivos da coleção de forma limpa. Isso é disruptivo se feito no local, então planeje backups, tempo de inatividade ou uma migração baseada em réplica.

mongodump --db myDatabase --collection orders --out /backup/mongo-dump

Após verificar o despejo e planejar a migração, restaure no ambiente de destino:

mongorestore --db myDatabase --collection orders \
  /backup/mongo-dump/myDatabase/orders.bson

Não descarte dados de produção até ter um backup verificado e um plano de reversão.

O Que Não Fazer

Não exclua manualmente arquivos WiredTiger, journal ou de coleção do sistema de arquivos. Isso pode corromper o banco de dados.

Não presuma que du e o tamanho lógico do MongoDB devem corresponder. Compressão, índices, espaço livre interno e comportamento do sistema de arquivos afetam os números.

Cuidado com conselhos antigos sobre pré-alocação estilo MMAPv1. Implantações modernas do MongoDB geralmente usam WiredTiger, e seu comportamento de armazenamento é diferente.

Conclusão Prática

Quando o uso de disco do MongoDB parecer errado, primeiro meça o host, depois meça bancos de dados, coleções e índices. Use índices TTL e arquivamento para desacelerar o crescimento. Descarte apenas índices confirmados como desnecessários. Para recuperação real de espaço no sistema de arquivos, planeje compact ou um fluxo de despejo e restauração, em vez de esperar que exclusões reduzam os arquivos imediatamente.