Hace poco tuve un problema con un servidor: se quedó sin espacio en disco. Al limpiarlo, empezó la base de datos a dar errores. Fuí al log de MySQL y me encontré con muchas líneas de error, pero el que me llamó la atención me decía que “Incorrect key file for table ‘/tmp/#sql_3c51_0.MYI’; try to repair it”. Básicamente era que no podía ejecutar SQL grandes porque el espacio en /tmp no era suficiente.

Las soluciones al error pasaban por hacer backup de todas las BD, descargártelas, borrar ciertos archivos y volver a restaurarlas, pero yo dudaba de que ese trabajo sirviera de algo. Entonces encontré esta explicación:

Por defecto, MySQL tiene asignado el directorio /tmp del raíz para hacer sus tareas. Cuando la partición raíz está llena, Debian (o Ubuntu en mi caso), crea en RAM una partición /tmp de 1 mega para que MySQL siga funcionando para las funciones básicas, pero no para traerse datos de uan web, por ejemplo. Si hacemos df -h, veremos una línea parecida a esta:

La solución consiste simplemente en borrar esa partición, y volverá a coger el directorio /tmp del raíz. Es decir, hacemos

Y para estar más seguros reiniciaremos el servicio de MySQL. Y todo arreglado.

 

A veces me he encontrado con que ha habido que corregir a mano la url o el nombre de la imagen de algún producto en una base de datos de Magento. Cuando esto pasa, hemos de saber que hay que trabajar con 2 tablas:

catalog_product_entity_varchar

catalog_product_entity_media_gallery

Si no nos interesan los logs, borraremos todos los registros de las tablas
log_customer
log_visitor
log_visitor_info
log_url log_url_info
log_quote
report_viewed_product_index
report_compared_product_index
report_event
catalog_compare_item

Se puede meter en cron para que salte la limpieza 1 vez al mes, por ejemplo:
php -f shell/log.php clean

También puede hacerse en la interfaz del administrador: Sistema->Configuración->Avanzado->Sistema->Log
Habilitamos la limpieza de logs y definimos la frecuencia de borrado. Guardamos y ya está todo.

Si nos interesan (por temas de estadísticas de visitas), dejaremos los del último mes o los 2 últimos meses.

Si administráis un sitio web que genera una gran cantidad de archivos temporales, como por ejemplo un sitio web de comercio electrónico, puede que en algún momento os encontréis con un error como este que os paraliza la web y, lo que es peor, os impide el acceso por phpMyAdmin:

[crayon-5ba28660857f3489858545/]

El error 28 nos está indicando que no tenemos espacio suficiente, como podemos comprobar fácilmente con el siguiente comando:

[crayon-5ba2866085800998020512/]

Pero una simple comprobación nos indica que aún tenemos más de un 40% del disco duro libre, luego el problema no es exactamente ese. Optamos entonces por intentar reparar la tabla en cuestión, sin éxito. La tabla sigue “marked as crashed” y al ejecutar el comando repair se nos muestra un error diferente:

[crayon-5ba2866085804263611449/]

No puede crear un archivo temporal pese a tener casi medio disco duro vacío. Al ser un sitio web con muchos archivos, puede que el problema esté en los inodes (inodos, en español). Los inodes son unas estructuras de datos de Linux (y otros SO) que contienen las características de cualquier objeto del sistema de ficheros, ya se trate de archivos, directorios o enlaces simbólicos. En una web de este tipo y sin la configuración adecuada, puede que el número de inodes crezca y crezca hasta bloquear el sistema.

Para comprobar si este es el caso, ejecutamos df -i, lo que nos devuelve el siguiente resultado:

[crayon-5ba2866085808384942149/]

Ese 100% en /dev/sda1 nos confirma que estamos sobre la pista correcta. Ahora hay que averiguar la ubicación exacta de esos inodes. Para ello vamos ejecutando este comando, empezando por el directorio raíz y profundizando poco a poco, para localizar cuál es el directorio que está saturado.

[crayon-5ba286608580c059738362/]

Esto nos devuelve una lista con el número de archivos de cada directorio. Nos adentramos a cada paso en aquél con mayor número de archivos, cambiando únicamente la ruta del for del comando por la ruta del directorio en cuestión. En nuestro ejemplo, esta búsqueda nos lleva finalmente hasta un directorio de sesiones de nuestra plataforma de e-commerce que contiene más de 76 millones de archivos.

La solución parece sencilla: borrar esos 76 millones de archivos, pero eso no es algo que Linux nos permita hacer con un simple rm * de los archivos anteriores a una determinada fecha.  Son demasiados archivos. En un caso como este, debemos echar mano del útil comando xargs, que divide la lista de archivos en sublistas a las que va aplicando sucesivamente el comando de borrado. Otro detalle a tener en cuenta en este caso es el tiempo de sesión, pues no debemos borrar los inodes de sesiones activas, de modo que el comando queda así:

[crayon-5ba2866085811167487362/]

Y esto es todo. Para un caso como este con varios millones de archivos a borrar, debéis esperar un poco a que la plataforma vuelva a estar operativa.