Speed up rsync

Hace un tiempo en Speed up rm, les conté como ejecutar en paralelo muchos rm’s para borrar muchos archivos. ¡Pues ahora les traigo lo contrario!

¿Qué pasa cuando quienes copiar muchos archivos o directorios que son muy grandes?  ¡Pues acá el paralelismo también nos ayuda!

Usualmente se usa rsync para este tipo de labores, pero cuando son muy grandes y muchos, esto se puede volver brutalmente lento.

Por ejemplo, si quisiéramos copiar todos los datos del un servidor mysql hacia el /var/lib/mysql/data de otro servidor podemos ejecutar algo como esto:

cd /var/lib/mysql/data
ls | xargs --max-procs=4 -I% rsync -avz % root@servidorDestino:$PWD/

Con esto, vamos a ejecutar 4 rsync’s en paralelo con 1 archivo o directorio cada uno (ya que -I implica –max-args=1), desde el servidor local al servidorDestino.

Notas:

  • En el servidor local, se debe bajar el servicio mysql primero, do’h!
  • Se asume que el directorio /var/lib/mysql/data está creado y vacio en el servidor de destino.
  • Se utilizó ssh para realizar la conexión.
  • La autenticación se realizó utilizando llave ssh. Esto es altamente recomendable, si no, por cada rsync deberán introducir una contraseña.

¡Ojalá les sirva!

Speed up rm

¿Han tenido alguna vez que borrar muchos archivos en un mismo, pero son tanto que se aburren de esperar que eso suceda?

Pues, a mi me pasa regularmente con directorios que contienen millones de archivos pequeños.

Acá, rm es muy lento, ya que el borrado se hace en serie… uno por uno… Seremos abuelos antes de que termine. 🙁

¿Y no se puede paralelizar?
Por supuesto que si se puede acelerar rm!!

Que les parece si creamos 100 procesos de rm que borren 1000 archivos cada uno?

ls | xargs --max-args=1000 --max-procs=100 rm -f

Y bueno, pueden ser tan creativos como quieran….

find $directory -mmin +$seconds -type f | xargs --max-args=1000 --max-procs=100 rm -f {} \;

Que lo disfruten! 😉

Guía para hacer cafe

Hace más de 1 año que no escribo nada por acá, no me siento nada orgulloso, ni tampoco merezco una medalla por ello. No tengo ni que pensar mucho para encontrar el porque, es solo por tiempo… pero porque no me hago el tiempo de escribir algo.

La imagen es antigua, pero la encontré hace unos días, y pensé que era algo bueno para re-comenzar a escribir en mi blog.

Yo reconozco que el espresso doble es el mio.
¿Y el tuyo?

Recuperar RHEL 5.2 luego de actualizar

Mientras que aún era sysadmin del LabComp (creo), leí en el Changelog de CentOS 5.3, que existía un error conocido con la actualización. Como deben saber, CentOS es la versión recompilada y sin soporte de RHEL.

Hoy cometí el error de hacer un ‘yum -y update‘ a un RHEL 5.2, así a secas. Si, olvidé por completo la recomendación (que sigo aplicando en nuevas versiones) del Changelog.

Pues yum descargó todos los rpms, ejecutó el test de la transacción con éxito, y cuando estaba ejecutando la transacción de la instalación, antes de instalar el primer rpm comenzó la pesadilla.

Traceback (most recent call last):
 File "/usr/bin/yum", line 29, in ?
 yummain.main(sys.argv[1:])
 File "/usr/share/yum-cli/yummain.py", line 183, in main
 base.doTransaction()
 File "/usr/share/yum-cli/cli.py", line 408, in doTransaction
 self.runTransaction(cb=cb)
 File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 599, in runTransaction
 errors = self.ts.run(cb.callback, '')
 File "/usr/lib/python2.4/site-packages/yum/rpmtrans.py", line 315, in callback
 self._instCloseFile(  bytes, total, h )
 File "/usr/lib/python2.4/site-packages/yum/rpmtrans.py", line 378, in _instCloseFile
 self.ts_done(txmbr.po, txmbr.output_state)
 File "/usr/lib/python2.4/site-packages/yum/rpmtrans.py", line 211, in ts_done
 te_fn = '%s/transaction-done.%s' % (self.base.conf.persistdir, self._ts_time)
AttributeError: RPMTransaction instance has no attribute '_ts_time'

Y luego, al intentar hacer algo, aparecía:

There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

 libelf.so.1: cannot open shared object file: No such file or directory

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.4.3 (#1, Jan 14 2008, 18:32:40)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)]

If you cannot solve this problem yourself, please go to
the yum faq at:
 http://wiki.linux.duke.edu/YumFaq

Luego de correr en círculos con las manos en el aire, llegué a la conclusión de eso no arreglaría mi problema. Efectivamente esa libreria dinámica (que es de la base del sistema) ya no existía…. OMG!!!!!

Sin siquiera leer detalladamente el error, borré la base de datos de los rpm’s y la reconstruí. Grave error, ya que solo emperó mi problema.

Probé durante un buen rato, tratar de resolver las dependencias de yum a mano para poder hacerlo funcionar…. mala idea, es interminable… por algo se crearon herramientas como yum para que lo hagan por ti. Utilizar las opciones –nodeps puede ser altamente riesgoso.

Lo que se me ocurrió luego de un par de horas de agonía y autoflagelación, fue mirar en el cache de yum si estaban los RPM’s que había descargado.

Miré en /var/cache/yum/rhel-i386-server-5/packages y efectivamente estaban los 352 rpms que tenia que actualizar…

Finalmente un rpm -Uvh –force * en ese directorio arregló mi problema. 😀

La moraleja de la historia, es que cuando hagan este tipo de cosas estén concentrados y siempre sigan las recomendaciones de los ChangeLog… y actualicen siempre la glibc, yum y rpm antes del resto del sistema.

Ahora tengo un RHEL 5.5 al día…. y lo mejor… es que funciona. 😛

Empire Avenue

Empire Avenue es una nueva red social, en donde la influencia de las personas influye demasiado.

¿Como es eso?
Pues, porque la popularidad se ve reflejada en el valor de tu “acción”.

Si, muy raro… pero pueden comprar mis acciones en:
http://www.empireavenue.com/RNT

Esta en estado de beta, y la entrada es con invitación. Se ve entretenido para un rato… pero no puedo asegurar nada a la larga. 😛

EAVB_GGGPBISVBM