[IRC-DEV] Cadenas de dominó curiosas

[Jesus Cea Avion]

El jueves pasado Gaia.irc-hispano.org estuvo caído un buen rato a media
tarde. Ello afectaba también a Olimpo, claro, dado que Gaia actúa de HUB
para ese servidor virtual, donde está agenda, nick2, chanlog, dxcluster
y unos cuantos bots más.

Voy a dar aquí los detalles por lo "curioso" del asunto.

La caída de Gaia fue ocasionada por quedarse sin disco duro en la
partición de IRC y fallar al intentar grabar un nuevo registro en la
BDD.

Esa partición tiene bastante espacio libre normalmente, así que mi
primera sospecha fue "chanlog" y el espacio que ocupaban esos logs. Los
copié a otra partición con varios gigabytes libres y actualicé "chanlog"
hacia el nuevo PATH de grabación.

Lanzo "gaia" y tarda un buen rato en "normalizarse", ya que al grabar la
BDD de forma incompleta en el primer punto, debe recibir una copia
actualizada de la red. Esto es un "bug" y ya está parcheado en los IRCDs
de esta semana: si intentamos grabar un registro en la BDD y fallamos,
intentamos dejar la BDD como estaba. Por supuesto al reiniciar el IRCD
se producirá una verificación de la integridad de la BDD que, si es
preciso, pedirá una copia al resto de la red. Pero solo si es necesario.

En este caso gaia recibí auna copia de la BDD de la red, pero cuando
estaba llegando al final, vuelve a fallar.

Dado que ya no podría echar la culpa a "chanlog" (movidos a otra
partición) me pongo a revisar el disco y me encuentro 130 megabytes en
el directorio de la Berkeley DB, de logs de transacciones. Unos 65
ficheros. Algo teóricamente imposible.

Los logs de transacciones de la BerkeleyDB son ficheros "append" en los
que se van guardando las transacciones antes de hacer un "checkpoint" y
comprometer la versión definitiva en la base de datos en sí. La idea es
que grabar un fichero en modo "append" es mucho más rápido que guardar
bloques sueltos repartidos por un fichero de base de datos que puede
medir gigabytes.

Uno de los procesos de Olimpo es hacer un "checkpoint" de vez en cuando
y eliminar los ficheros de logs de transacciones que ya no son
necesarios. De esa forma mantenemos los últimos dos o tres ficheros de
transacciones, nada más. Eso son unos 4-6 megas de disco.

Pero había unos 130 megabytes de disco y 65 ficheros.

Utilizando las herramientas apropiadas para escanear los ficheros de
logs de transacciones, veo que hay transacciones del día anterior,
"abiertas" y "no comprometidas". ¿Un bug?.

No un "bug", sino un "atajo": El procedimiento de recuperación de
"olimpo" señala claramente que ante "core dumps" hay que hacer una
recuperación de la base de datos Berkeley DB a partir de sus logs (razón
por la que me interesan pocos ficheros de logs, y pequeños). Este
proceso, normalmente, lleva apenas uno o dos segundos.

El problema más evidente si no se hace una recuperación de transacciones
es el "deadlocking" de Olimpo, al intentar acceder a un registro de la
base de datos "bloqueado" por una transacción previa. Esto se produce
normalmente en el mismo instante de arrancar el proceso, ya que accede a
registros muy "calientes" y que normalmente estarían bloqueados sin una
recuperación de BD previa.

Pero en un cambio reciente de Olimpo, programé un esquema de detección y
solución de "deadlocks". Ahora mismo Olimpo detecta "deadlocks" y se
carga el bloqueo más "antiguo", por entender que procede de una
ejecución anterior no "recuperada".

Pero claro, con ese cambio Olimpo ya no se bloquea sino que continúa su
ejecución como si nada... El bloqueo previo es eliminado, pero NO ASÍ SU
TRANSACCIÓN ASOCIADA, que sigue en los ficheros de logs, pendiente de
que alguien le dé un "commit" o un "abort".

Y mientras haya transacciones "pendientes" de completarse (en un sentido
u otro), los ficheros de logs de transacciones no se pueden eliminar,
por no saberse si van a ser necesarios o no.

Una vez localizado el problema, bastaba con "parar" Olimpo, ejecutar una
recuperación bastante larga (2-3 minutos), porque habría muchos ficheros
de logs de transacciones antiguos, y lanzar Olimpo de nuevo.

Moraleja: Los procedimientos están por algo. Si un procedimiento
contiene pasos cuyo significado no es evidente o parecen superfluos, hay
que documentar su objetivo, para que los "listos" no tomemos atajos :-).
Asimismo, cuando cambie el entorno, hay que revisar los procedimientos,
por si se han vuelto anticuados.

En este caso, una mejora aparentemente "inocua" en Olimpo, hace meses,
provocó un buen susto, por no seguir "el manual".

PS: En reconocimiento al buen hacer de la Berkeley DB, no se ha perdido
ni un solo registro a pesar de fallar varias veces varios demonios,
llenarse el disco duro, etc. Llevo años trabajando con ellos y he de
decir que son excepcionales. Por si alguien tiene curiosidad,
http://www.sleepycat.com/. Habría que hacerles una donación :).

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz