Gestión y Liberación de Espacio en Disco en Despliegues de MongoDB

Los problemas de espacio en disco de MongoDB suelen manifestarse de dos maneras: el sistema de archivos está casi lleno, o MongoDB parece grande incluso después de eliminar datos. El segundo caso sorprende a muchos equipos porque WiredTiger puede reutilizar internamente el espacio liberado sin devolverlo inmediatamente al sistema operativo.

Su objetivo es diferenciar entre crecimiento real, espacio libre interno reutilizable, índices sobredimensionados y fragmentación que requiere una ventana de mantenimiento.

Verifique el Uso de Disco a Nivel de Host

Comience con el sistema de archivos que contiene el dbPath de MongoDB. MongoDB no puede seguir escribiendo de forma segura si ese volumen se llena.

df -h /var/lib/mongodb

También verifique qué directorios están creciendo:

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

Use su dbPath real; /var/lib/mongodb es común en paquetes de Linux pero no universal.

Verifique las Métricas de Almacenamiento de MongoDB

Dentro de mongosh, compare el tamaño lógico de los datos con el tamaño de almacenamiento asignado.

use myDatabase
db.stats()

Los campos útiles incluyen:

• dataSize: Tamaño lógico de los datos de los documentos.
• storageSize: Espacio asignado para los datos de la colección.
• indexSize: Espacio utilizado por los índices.

Para una colección específica:

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

Observe size, storageSize y totalIndexSize. Si storageSize es mucho mayor que size, la colección puede tener espacio interno reutilizable de actualizaciones y eliminaciones. Si totalIndexSize es grande, los índices pueden ser la forma más rápida de reducir el uso de disco.

Causas Comunes del Crecimiento de Disco en MongoDB

La alta rotación de eliminaciones y actualizaciones puede dejar espacio libre interno dentro de los archivos de WiredTiger. MongoDB a menudo reutilizará ese espacio para futuras escrituras, pero el sistema operativo aún puede mostrar los archivos como grandes.

Los índices también pueden consumir una gran parte del disco. Los índices compuestos, de texto, comodín y duplicados se acumulan rápidamente.

Las brechas de retención son otra causa común. Las colecciones de registros, sesiones, eventos y auditorías crecen indefinidamente a menos que archive o expire documentos antiguos.

Formas Seguras de Reducir el Crecimiento Futuro

La mejor solución para el disco suele ser prevenir el crecimiento ilimitado.

Para datos basados en tiempo, cree un índice TTL:

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

La eliminación TTL es manejada por un monitor en segundo plano y no es instantánea al segundo. Sigue siendo una buena opción para registros, sesiones y eventos temporales donde el momento exacto de la eliminación no es crítico.

Revise los índices antes de eliminar algo:

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

$indexStats puede mostrar si un índice se ha utilizado desde que se inició el proceso. Trátelo como una pista, no como una prueba. Un índice de informe mensual puede parecer no utilizado en una semana tranquila.

Elimine un índice confirmado como no utilizado por su nombre:

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

Recupere Espacio de Archivos Existentes

Eliminar documentos generalmente no reduce el tamaño de los archivos de WiredTiger en disco. Para devolver espacio al sistema de archivos, necesita una estrategia de reescritura o compactación.

Use compact con Cuidado

compact puede reescribir los datos de la colección y los índices para reducir el uso de disco. Es intensivo en recursos y puede bloquear operaciones en la colección afectada, dependiendo de su versión de MongoDB y despliegue.

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

Ejecútelo durante una ventana de mantenimiento, pruébelo primero y lea la documentación para su versión exacta de MongoDB. En conjuntos de réplicas, muchos equipos compactan un secundario a la vez, lo dejan ponerse al día, y luego cambian o rotan los miembros según sea necesario.

Volcado y Restauración para Fragmentación Severa

Para datos muy fragmentados, un volcado y restauración reconstruye limpiamente los archivos de la colección. Esto es disruptivo si lo hace en el lugar, así que planifique copias de seguridad, tiempo de inactividad o una migración basada en réplicas.

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

Después de verificar el volcado y planificar el corte, restaure en el entorno de destino:

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

No elimine datos de producción hasta que tenga una copia de seguridad verificada y un plan de reversión.

Qué No Hacer

No elimine manualmente archivos de WiredTiger, diario o colecciones del sistema de archivos. Eso puede corromper la base de datos.

No asuma que du y el tamaño lógico de MongoDB deben coincidir. La compresión, los índices, el espacio libre interno y el comportamiento del sistema de archivos afectan los números.

Tenga cuidado con los consejos antiguos sobre la preasignación al estilo MMAPv1. Los despliegues modernos de MongoDB suelen usar WiredTiger, y su comportamiento de almacenamiento es diferente.

Conclusión Práctica

Cuando el uso de disco de MongoDB parece incorrecto, primero mida el host, luego las bases de datos, colecciones e índices. Use índices TTL y archivado para ralentizar el crecimiento. Elimine solo índices confirmados como innecesarios. Para una recuperación real de espacio en el sistema de archivos, planifique compact o un flujo de trabajo de volcado y restauración en lugar de esperar que las eliminaciones reduzcan los archivos inmediatamente.