En esta oportunidad hablaré de como ejecutar rutinas de forma concurrente.
No pretendo abarcar demasiado explicando que es esto. Una explicación detallada puede ser conseguida en: http://es.wikipedia.org/wiki/Hilo_en_sistemas_operativos, por acá solo me limitaré a decir que es una manera de ejecutar rutinas en perl con la cual se aprovechan las bondades de multinucleo de los procesadores, permitiendo ejecutar una rutina varias veces de forma paralela.
du /home/user -lh --max-depth=1 | sort -rh | headEsto nos dará en orden descendiente los 10 directorios de mayor tamaño. (ojo cuidado porque el primero en listarse siempre será el indicado /home/user)
Dependiendo de la frecuencia con la que se instalan paquetes, se hacen pruebas e incluso se mezclan herramientas para instalar paquetes, nos podemos encontrar en un escenario donde terminamos con varios paquetes huérfanos, un ejemplo claro es durante una usuario que utiliza Synaptics para instalar paquetes, aptitude en un terminal y apt-get
Para generar una tabla con números aleatorios Postgresql, se puede hacer lo siguiente:
select id,random()*10000 as venta
from (
select * from generate_series(1,100) as id
) as x
Lo primero es hacer un auto-te lo dije, esto porque siempre he tenido pendiente que se debe respaldar la configuración del (los) volúmenes lógicos, pero usando como excusa una cosa y otra no lo hice; para hacer el cuento corto, me pasó.
Tenía un equipo Virtualizador con un raid1 y sobre este raid un LVM, uno de los discos comenzó a fallar pero como estaban en raid, estaba tranquilo, así que me dispuse a detener el disco y en ese momento todo fue cuesta a bajo, pues bien, cuando detuve el disco para sacarlo, el equipo se congeló (probablemente el disco estaba en corto, la verdad no lo sé)
Procedí a sacar el disco y reiniciar y mi sorpresa es que el equipo virtualizador no iniciaba, no me preocupé aún este punto, solo metí mi CD de debian, arranque en modo experto monte el raid, y un grub-install resolvió.
Reinicié el equipo y todo normal, a excepción de que una de las maquinas virtuales no arrancaba, por lo que me metí por vnc para ver que sucedía (en este punto es válido informar que a mi maquinas virtuales no les creo los discos usando archivos sino les entrego volúmenes LVM) mi sorpresa es que me dice que no encuentra los volúmenes lógicos para arrancar.
Respiro profundo y en la consola de initramfs hago un:
lvm
pvscan
Y me dice que encuentra el volumen pero que la metadata es inválida me comencé a preocupar.
Hago:
vgscan
Y me dice que no hay volúmenes lógicos definidos. Oficialmente preocupado.
Ya con esto comienzo a buscar en Internet y no encontré al menos de momento nada que me ayudara directamente. Salvo que personas con casos similares a los míos resolvieron volcando los primeros bits de la partición y de aquí sacaron el archivo de backup de lvm
Eso no funcionó para mi, pero si me orientó en el camino, ya que en esa página se asegura que el archivo de configuración se guarda al principio d ela partición, pero pensé que no necesariamente era mi caso, dado a que la partición la entrego desde el virtualizador en LVM y el a su vez esta partición la trabaja y la convierte a LVM. Tal véz el Journaling del virtualizador hizo su trabajo (solo especulo).
Así que hice lo siguiente:
Hice un volcado completo del disco (en mi caso /dev/sda5 donde estaba creado el volumen en la maquina virtual) a un archivo (lo llame salida) en mi nuevo disco:
dd if=/dev/sda5 of=salida.txt
Apagué la maquina virtual y monté el disco en el virtualizador.
Busqué en el archivo "salida.txt" la cadena "logical_volumes" y me hice una idea en que parte estaba las líneas que necesitaba (realmente en este punto fue suerte porque nunca había modificado el sistema de archivos y solo había una copia)
grep -a -n -i logical_volumes salida.txt
Con sed estraje ±100 líneas.
sed -n -e '201200,201300p' -e '201300q' > tmp.txt
En el nuevo archivo, con vim busque la cadena "#Generated" y al encontrarlo encontré la configuración, esta la pegue en un nuevo archivo llamado backup.conf
Ahora mi nuevo problema, la metadata sigue mala. Por lo que cambié el uuid para que reparara la metadata
pvchange -u /dev/sad5
Al ejecutar vgcfgrestore me daba error (lógico, el uuid del pv no coincida con el uuid del sda5).
Ejecute vgcfgrestore y funcionó.
vgcfgrestore -vvv -f /target/backup.conf
Reinicié la maquina virtual y arrancó sin problemas.
Mientras redacto este articulo me doy cuenta que los comandos sed y grep los pude haber ejecutado directamente sobre /dev/sda5, y de esta forma ahorrarme el volcado del disco, en fin, son cosas que se piensan luego con calma, si alguien lo puede probar.
Moraleja. Siempre sacar el archivo backup de la partición lvm y si es posible sacarlo del equipo.
Hay usuarios que cuando colocan en LVM toda la instalación de su distro, cambian la ubicación de los backups de los LVM para que lo haga en la partición sin LVM de arranque /boot esto es una alternativa. Ya que ante algún problema la partición se puede montar tranquilamente como un sistema de archivo.
No voy a entrar en el tema de si es un error de aplicación de base de datos, solo digamos que por algún motivo tienes un abrazo mortal o bloqueo mutuo en una base de datos, y es necesario ver quienes son los interlocutores (probablemente te des cuenta porque al menos uno de ellos te va a llamar) que intervienen en dicho abrazo mortal.