Cómo evitar que un contenedor de base de datos siga creciendo después de limpiar los datos
Un contenedor de base de datos puede seguir creciendo después de limpiar los datos porque las filas eliminadas, los registros de transacciones, los índices y los registros del contenedor siguen reglas diferentes para recuperar espacio.
No supongas que el volumen de la base de datos está creciendo solo porque aumenta la huella total de disco del contenedor. Mide por separado el directorio de datos de la base de datos, los directorios de WAL o binlog, el archivo de registro de Docker, la capa escribible y las rutas de copias de seguridad o temporales. Después, determina si el espacio eliminado de la base de datos se puede reutilizar internamente pero no se devuelve al host, si realmente es necesario reescribir los datos o si todavía está creciendo un archivo completamente distinto.
Mide qué ruta sigue creciendo
Registra el tamaño del volumen con nombre o del directorio de la base de datos montado mediante bind mount, de la capa escribible del contenedor, del registro del contenedor en el host, del directorio de registros de transacciones de la base de datos y de cualquier directorio de volcados o temporales antes y después de un ciclo de limpieza.
Una guía para solucionar problemas de espacio en disco de PostgreSQL parte del mismo principio: encuentra dónde está el espacio antes de elegir una operación para recuperarlo.
Si solo crece el registro de Docker, la limpieza de la base de datos es irrelevante. Si el archivo de datos sigue siendo grande, pero deja de aumentar después de la limpieza, es posible que el motor ya esté reutilizando las páginas liberadas aunque el sistema de archivos del host no muestre ninguna reducción.
Distingue el espacio reutilizable de la base de datos del espacio devuelto al disco
Muchas bases de datos transaccionales no eliminan inmediatamente los bloques de archivo del centro de una tabla después de borrar filas. Marcan o recuperan páginas internas para que las inserciones posteriores puedan reutilizar ese espacio, mientras el archivo subyacente conserva el mismo tamaño.
PostgreSQL ofrece un ejemplo claro: el comando VACUUM reutiliza el espacio internamente, pero normalmente no devuelve al sistema operativo esas regiones intermedias del archivo.
Observa si el archivo sigue creciendo durante las nuevas inserciones después de la limpieza. Un tamaño de archivo estable con una fragmentación interna cada vez menor es diferente de un crecimiento descontrolado y normalmente no justifica una reescritura de emergencia.
Usa el método de recuperación del motor de base de datos, no una limpieza genérica de Docker
Cuando el objetivo sea devolver capacidad al host, identifica primero el motor y el formato de almacenamiento. PostgreSQL, MySQL o MariaDB y SQLite no utilizan un único comando de reducción intercambiable, y algunas operaciones de recuperación reescriben archivos grandes o bloquean tablas.
Un artículo sobre almacenamiento de MySQL explica cómo OPTIMIZE puede reconstruir tablas de InnoDB, en lugar de considerar un DELETE como una prueba de que el host debería recuperar inmediatamente esos bytes.
Haz una copia de seguridad de la base de datos y confirma que tienes espacio de trabajo libre antes de cualquier operación que implique una reescritura considerable. Un sistema de archivos de un servidor doméstico casi lleno es el peor momento para ejecutar un comando que necesita una segunda copia de una tabla grande.
Comprueba por separado la retención de WAL, binlogs y replicación
Los registros de transacciones pueden crecer incluso después de eliminar filas antiguas de la aplicación. Un trabajo de archivado fallido, una ranura de replicación obsoleta, una réplica retrasada, una transacción prolongada o un requisito de conservación de copias de seguridad pueden mantener segmentos históricos de registros en el disco.
Una nota reciente sobre la recuperación de PostgreSQL muestra cómo la retención de WAL puede consumir almacenamiento de forma independiente de los datos de las tablas que un usuario acaba de limpiar.
No elimines manualmente archivos WAL o binlog del sistema de archivos. Corrige la causa de la retención mediante el motor de la base de datos y verifica después que el reciclaje normal se reanude.
Limita los registros de Docker y comprueba la capa escribible
Un contenedor de base de datos puede parecer que crece porque la salida estándar o de error se captura en un registro de Docker sin límites, o porque una exportación temporal, una caché o un archivo de base de datos se escribió en la capa del contenedor en lugar del volumen persistente previsto.
Un caso de Docker autohospedado señala que los registros de los contenedores pueden crecer indefinidamente cuando no se configura la rotación.
Relaciona cada archivo grande del host con su ruta dentro del contenedor antes de eliminar nada. Configura la rotación de registros para evitar crecimientos futuros y mueve el estado de la base de datos a un volumen explícito en lugar de depender de la capa escribible efímera.
Verifica que la limpieza genere margen sostenible
Después de aplicar el paso de recuperación elegido, ejecuta la carga de escritura habitual durante un periodo representativo y compara el espacio libre del host, el tamaño de los archivos de la base de datos, el tamaño de los registros de transacciones, los registros de Docker y las métricas internas de espacio libre o fragmentación.
Una guía para reducir el almacenamiento de PostgreSQL destaca que la reducción requiere un mantenimiento específico, en lugar de asumir que cada eliminación debería reducir de inmediato el tamaño del archivo del sistema operativo.
La solución se completa cuando el crecimiento esperado de la base de datos se reutiliza o se mantiene acotado, y el host deja de perder capacidad inexplicada después de cada ciclo de limpieza. La guía relacionada de ZimaSpace sobre copias de seguridad coherentes de contenedores de bases de datos proporciona el límite de reversión antes de cualquier operación que reescriba archivos de la base de datos.
Preguntas frecuentes
¿Por qué borrar millones de filas a veces libera muy poco espacio en el disco del host?
El motor puede marcar esas páginas como reutilizables dentro del archivo de la base de datos en lugar de truncar el propio archivo. Esto puede evitar un crecimiento futuro sin cambiar el tamaño del archivo visible en el host.
¿Debería ejecutar una reescritura completa cada vez que el contenedor aumenta de tamaño?
No. Las operaciones que implican una reescritura considerable pueden requerir bloqueos, espacio temporal y una cantidad importante de E/S. Úsalas solo cuando sea necesario devolver espacio al host y comprendas los riesgos específicos del motor.
¿Docker prune puede recuperar un volumen de base de datos?
No de forma segura cuando el volumen sigue formando parte del estado persistente de la base de datos. Identifica si el espacio pertenece a registros, imágenes, contenedores detenidos o datos activos de la base de datos antes de ejecutar la limpieza.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
