El fin de semana pasado mi sitio decidió tomarse unas vacaciones sin avisar y dejó de estar disponible. En pantalla solo aparecía este mensaje superútil:
The website encountered an unexpected error. Please try again later.
Cuando intenté entrar por consola usando el panel de Digital Ocean, tampoco me dejó. Así que, como todo buen informático, apliqué la solución universal: reiniciar la instancia. Y sí, con eso pude entrar.
Lo primero que hice fue preguntarle a ChatGPT cómo ver qué carpetas estaban devorando mi disco, y me pasó este comando mágico:
du -h --max-depth=1 / | sort -rh | head -10
Con esto descubrí que mi servidor estaba acumulando logs como si fueran tesoros. En particular, la carpeta /var/log/journal pesaba unos jugosos 2GB. Me puse a investigar y, con otro comando que me pasó ChatGPT, filtré los intentos de acceso con:
journalctl --file system@bbfa76cf12a94546b8be21fe7a07d96f-0000000001bd46ca-00062d997baa0eca.journal | grep "Accepted password"
Spoiler: no había intrusos, solo yo mismo logueándome :D . Para borrar esos logs, ChatGPT me sugirió este combo:
sudo journalctl --rotate
sudo journalctl --vacuum-size=1K
Con eso me deshice de casi 2GB de basura.
Puedes ver el video al respecto donde voy haciendo el procedimiento a prueba y error:
¿Y qué pasaba con MySQL?
Después fui a ver qué onda con la carpeta /var/lib/mysql, que estaba ocupando la módica cantidad de 14GB. Resulta que se estaban generando montones de archivos de binlog, esos logs binarios que MySQL/MariaDB usa para replicación o recuperación de datos. Como yo no uso replicación, estaban ahí ocupando espacio de gratis.
Le pedí a ChatGPT un comando para leerlos, y me dio:
mysqlbinlog /var/mysql/binlog.001017
¿Lo entendí? Pues no, pero me di cuenta de que Drupal estaba logueando en las tablas de logs/cache como si no hubiera un mañana. Así que la primera medida fue vaciar la caché de Drupal.
Para deshacerme de los binlogs viejos, ejecuté esto en MySQL:
PURGE BINARY LOGS BEFORE NOW() - INTERVAL 30 DAY;
Y para deshabilitarlos de una vez por todas, edité el archivo de configuración en /etc/mysql/mysql.conf.d/mysqld.cnf y agregué esto al final:
[mysqld]
skip-log-bin
Después reinicié MySQL con:
sudo systemctl restart mysql
Y con eso bajé el uso de disco de MySQL de 14GB a solo 1.6GB. ¡Victoria! 🎉
También hice un video continuado todo lo anterior expuesto.
Resumen de la Operación Rescate Espacio en Disco:
- Rotar y eliminar logs de journal.
- Vaciar caché de Drupal.
- Borrar binlogs de MySQL.
- Deshabilitar binlogs de MySQL.
- Reiniciar MySQL.
Conclusión
Parece que el servidor se quedó sin espacio en disco, lo que provocó la caída del sitio. Las principales razones fueron:
- Montones de intentos de acceso al servidor generando logs interminables.
- Drupal logueando como si le pagaran por cada línea guardada.
- MySQL acumulando binlogs sin que nadie los usara.
Moral de la historia: el disco no es infinito y el mantenimiento preventivo es nuestro amigo. 😅 ¡Hasta la próxima crisis! 🚀
Comentarios