Miércoles, 22 de abril de 2009
Hoy me encontré con un problema en un simple script que hice para backupear algunas bases de datos MySQL:
#!/bin/sh
# Hace dumps de MySQL de las BBDDs especificadas
DBS="db1 db2 dbN"
DUMPDIR="/root/mysql-dumps"
ADMIN="alertas@midominio.com"
REPORT="/tmp/mysql-dump-bases-importantes.$$.log"
ERRORS=0
HOSTNAME=`hostname -f`
cd $DUMPDIR
for db in $DBS
do
/usr/bin/mysqldump -Q $db | gzip -9 > dump-$db-`date +"%F_%T"`.sql.gz
ERR=$?
if [ "$ERR" == "0" ]; then
echo "Dumping database '$db' done OK" >> $REPORT
else
echo "Dumping database '$db' FAILED" >> $REPORT
ERRORS=1
fi
done
if [ "$ERRORS" == "0" ]; then
cat $REPORT | mail -s "MySQL Dumps on $HOSTNAME: OK" $ADMIN
else
cat $REPORT | mail -s "MySQL Dumps on $HOSTNAME: ERRORS" $ADMIN
fi
rm $REPORT
Este script usa mysqldump para sacar una imágen de cada base de datos, y supuestamente guarda en la variable $ERR el valor de salida para enterarnos en caso que haya problemas, y mandar así el mensaje adecuado en el reporte.
El problema que tiene este script es que la variable $? retorna el valor de salida del último comando en un pipe, en mi caso corresponde a la salida del gzip, que siempre sale correctamente (al menos en este script). Entonces ¿cómo nos enteramos que pasó con un comando anterior en la cadena?
Bash (no conozco otros shells) tiene una variable $PIPESTATUS, que es un array con los valores de salida de una serie de comandos encadenados, por lo tanto lo único que hizo falta para corregir este programa, es reemplazar la línea que dice:
ERR=$?
…por lo siguiente:
ERR=${PIPESTATUS[0]}
El subíndice 0 corresponde al primer valor del array, y que coincide con el primer comando de la cadena de comandos.
¡Espero les sirva en algún momento!
Martes, 9 de septiembre de 2008
Hace unos pocos minutos me encontré con un artículo que me alegró la semana.
Nokia Research Center ha desarrollado una implementación de Map/Reduce, una de las herramientas que Google utiliza para el procesado de inmensas cantidades de información.
El funcionamiento de Map/Reduce a grandes rasgos consiste en partir el conjunto de datos en pequeños segmentos y distribuir datos y código de ejecución en diferentes computadoras (Map) para que trabajen en paralelo. El resultado de este procesamiento luego es recuperado e integrado en un solo lugar para su procesamiento final y uso (Reduce). Se puede leer más acerca del tema en el paper publicado por Google.
Nokia Research Center comenzó un proyecto denominado Disco Project, que consiste en un servidor implementado en Erlang que nos permite como usuarios ejecutar scripts en Python (si, leyeron bien!) en forma distribuida y masiva.
En el sitio del proyecto tenemos un lindo tutorial que podemos probar desde nuestra propia PC, si tenemos un CPU multicore y GNU/Linux, claro está
Lunes, 29 de octubre de 2007
Hace unas semanas estuve en la edición 2007 de CaFeCONF, donde asistí a una muy buena presentación sobre desarrollo de juegos usando Python y Pygame. Afortunadamente los expositores la filmaron y publicaron en Google Video, así que hago mi parte en publicitarla, se las recomiendo!
Lunes, 5 de junio de 2006
Anteayer sábado 5 de Junio se realizaron unas Jornadas Pythonescas organizadas por miembros del LUGLi, con ayuda de la UTN-FRSF y otros auspiciantes, incluida mi empresa LUNIX. El dictado de las charlas fue realizado por dos integrantes del grupo PyAR: Facundo Batista y Lucio Torre.
Desde mi humilde rinconcito de la blogósfera quiero felicitar a Juan José Conti, César Portela, Mariano Galán y su grupo de ayudantes, por un excelente trabajo en lo que es la organización de un evento que llenó las espectactivas de todos. Algo así es mucho trabajo, y ellos lo realizaron de manera espectacular.
No puedo también dejar de alegrarme por la buena disposición de la UTN para el armado de un evento de esta naturaleza, espero que se repitan mucho más así mostramos a los alumnos de ingeniería que no todo en la vida son los productor de Microsoft.
Actualización: Me han entregado fotos sacadas en el evento que acabo de publicar en mi galería, que las disfruten!
Lunes, 13 de febrero de 2006
Después de mucho tiempo, me puse este fin de semana a programar un poco, siguiendo la serie de mejoras de la consola PyGTK para Bacula, el servidor de backups libre que comenté hace unos días.
Estos días estuve trabajando en un feature esencial para la aceptación de la consola como herramienta útil: la capacidad de hacer un restore parcial, es decir… seleccionar archivos a restaurar de una lista de archivos que el director nos presenta.
La interfaz de consola de Bacula ofrece al usuario un pseudo-shell que permite navegar por una estructura de directorios, y marcar los archivos o directorios seleccionados para la restauración. Al principio cuando pensaba como encarar esto, me complicaba con difíciles estructuras de árbol que se suponía que debía mantener, y por eso me estaba tardando mucho en el diseño de esta parte del programa. Finalmente deseché esa idea y lo que decidí hacer es simplemente simular el comportamiento de un operador, armando métodos de cambio de directorio y pedido de listado. No guardo en ningún sitio estas estructuras complicadas, ¿para qué? si el Bacula se encarga de eso! una buena auto-lección de programación… Keep It Simple, Stupid
Quedan cosas a completar, como por ejemplo…una columna para seleccionar los archivos! je, je…bueno pero lo que estoy mostrando es lo más complicado, el resto viene casi solo.
Comentarios recientes