Automatiza el mantenimiento de directorios temporales en Linux

cleanNo sé cómo he podido vivir tanto tiempo sin conocer tmpwatch, una herramienta que suele venir con el sistema y que nos permite automatizar el mantenimiento de directorios que por su naturaleza, acumulan ficheros temporales que pocas veces se vuelven a usar. tmpwatch, por lo tanto, busca los ficheros y directorios antiguos en una determinada ubicación, y los elimina de forma recursiva. Lo que antes solía hacer con una instrucción como la siguiente, ahora lo haré con tmpwatch:

# eliminación ficheros con más de 365 días desde la última modificación desde el directorio actual
find . -mtime +365 -exec rm {} \;

# eliminación ficheros con más de 365 días desde la última modificación desde el directorio actual y sub-directorios
find . -depth -mtime +365 -exec rm {} \;

Un ejemplo muy claro, es usar tmpwatch para eliminar los ficheros que no se han usado (access time) en los últimos x días (o meses) dentro de directorios como /tmp o ~/Downloads. En cuanto a servidores, seguro que tendemos la típica aplicación que va dejando cientos de archivos temporales en una determinada ubicación, que hemos de estar borrando cada cierto tiempo ya sea a mano o con algún script programado en el cron.

Continuar leyendo «Automatiza el mantenimiento de directorios temporales en Linux»

MongoDB: Recuperar un config server

mongodbHoy me he encontrado, que tras una caída de un servidor que alojaba un config server de mi cluster MongoDB 2.2.0 (sobre un entorno Red Hat), el config server no era capaz de arrancar. Concretamente, al intentar iniciar el config server, podría ver los siguientes logs en el fichero de error:

Thu Sep 12 11:47:37 [initandlisten] dbexception during recovery: 15874 couldn’t uncompress journal section
Thu Sep 12 11:47:37 [initandlisten] exception in initAndListen: 15874 couldn’t uncompress journal section, terminating
Thu Sep 12 11:47:37 dbexit:
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to close listening sockets…
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to flush diaglog…
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to close sockets…
Thu Sep 12 11:47:37 [initandlisten] shutdown: waiting for fs preallocator…
Thu Sep 12 11:47:37 [initandlisten] shutdown: lock for final commit…
Thu Sep 12 11:47:37 [initandlisten] shutdown: final commit…
Thu Sep 12 11:47:37 [initandlisten] shutdown: closing all files…
Thu Sep 12 11:47:37 [initandlisten] closeAllFiles() finished
Thu Sep 12 11:47:37 [initandlisten] shutdown: removing fs lock…
Thu Sep 12 11:47:37 dbexit: really exiting now

Al parecer, el fichero de journal se ha corrompido con la caída del server y ni si quiera es capaz de solucionarse con un «–repair». Aprovechando que mi cluster tiene 3 config servers, he pasado a parar uno de los dos config servers que aun funcionaban, para copiar los datos del dbpath al config server corrompido, con tal de recuperarlo.

El proceso ha sido el siguiente, descrito en la documentación oficial de MongoDB (v2.2): Continuar leyendo «MongoDB: Recuperar un config server»

Limpieza y rotación del slow-query-logs

cleanupYa hablamos de cómo limpiar de forma segura el error-log de MySQL. Otro fichero de logs que puede dar problemas, si lo tenemos activado, es el slow_query_log, que se encarga de almacenar las queries que se han ejecutado sin índices, o que han tardado más de determinados segundos en ejecutarse. Este fichero, por tanto, nos debería servir para identificar puntos de mejora en nuestras queries, pero si tenemos mucho que mejorar, se llenará rápidamente. En mysqlperformanceblog explican cómo crear un script para uso de logrotate para limpiar de forma automática este log de forma periodica, y evitar así problemas mayores.

Primero, crearemos el script de rotación, cogido directamente de mysqlperformanceblog:

[root@myserver]# vi /etc/logrotate.d/mysql-slow

/var/lib/mysql/mysql-slow.log {
nocompress
create 660 mysql mysql
size 1G
dateext
missingok
notifempty
sharedscripts
postrotate
/usr/bin/mysql -u logrotate -pmipassword -e ‘select @@global.long_query_time into @lqt_save; set global long_query_time=2000; select sleep(2); FLUSH SLOW LOGS; select sleep(2); set global long_query_time=@lqt_save;’
endscript
rotate 5
}

Se ha de tener en cuenta, que en la instrucción de postrotate, necesitaremos añadir el usuario y password de acceso al mysql para poder ejecutar esas consultas. También se deberá indicar la ruta al fichero del slow-log en la primera instrucción (marcado en negrita).

Continuar leyendo «Limpieza y rotación del slow-query-logs»