Olimpo (Re: [IRC-DEV] Cadenas de dominó curiosas)

[Jesus Cea Avion]

> En fin lo que yo queria comentar es que si el  esquema de detección y
> solución de los callejones sin salida consiste en la carga del bloqueo
> mas antiguo, esto va en contra de la filosofia de pocos megas de
> espacio en disco y la incertidumbre de cual sera la informacion
> necesaria de los logs de transacciones

No. Todo lo contrario. Lo aclaro más abajo.

>, ya que, y esta es la pregunta: ¿Que parámetro mide la
> minima antiguedad o su aproximacion para determinar que un log no sera
> necesario posteriormente?

Cada transacción tiene una fecha y un identificador. En un momento
determinado, una transacción puede estar en cinco estados "virtuales":

- En progreso.

- Comprometida en el LOG.

- Comprometida en la base de datos.

- Abortada.

- Zombie.

Las transacciones "zombie" son transacciones provenientes de ejecuciones
previas, posiblemente debido a un "casque" del servidor en medio de una
operación de base de datos, fallo eléctrico, etc. No están completadas,
así que la única opción es hacerles un "rollback" y dejar la base de
datos como si no hubiera pasado nada. Para poder hacer ese "rollback" se
necesitan los ficheros de "logs" de transacciones.

Una vez que una transacción es abortada o está comprometida en la base
de datos, ya no es necesaria en el log. Ese log se puede borrar.

Si una transacción está comprometida, pero solo en el LOG, no se puede
borrar hasta que se ha pasado a la base de datos. Eso es algo que hace
"Olimpo" en "background", automáticamente. En cuanto se pasa a la base
de datos, estaríamos en el caso descrito en el párrafo anterior.

Lo que hace Olimpo en "background" es hacer "checkpoints" periódicos de
las transaciones completadas en el log a la base de datos y eliminar
ficheros de logs "innecesarios". Un fichero de log es innecesario cuando
no se necesita para recuperar la base de datos en caso de fallo.

Para los cinco estados de las transacciones tenemos:

1. En progreso: Acabará en estado 2 o 4.

2. Comprometida en el LOG: Acabará en estado 3.

3. Comprometida en la base de datos: Ya no es necesaria en el "log".

4. Abortada: Ya no es necesaria en el "log".

5. Zombie: Pánico. ¡¡Algo ha pasado!!.

Puede verse que si todo va bien las transacciones siempre acaban en un
estado en que se pueden borrar del log. La única excepción es el caso 5.
Aunque podría hacer una recuperación automática, prefiero que sea una
operación manual por mi parte porque si ocurren cosas raras, prefiero
enterarme.

La recuperación de la base de datos supone revisar los logs, y pasar
cada transacción del estado 5 al estado 4 (abortar), junto con las
operaciones necesarias de actualización de la base de datos.

De hecho el cambio de "eliminar el bloqueo más antiguo" en Olimpo fue un
intento de automatización del punto 5. De lo que no me di cuenta es de
que eliminar el bloqueo no implica eliminar la transacción que lo
ocasionó, lo que, por cierto, es un bug por mi parte, documentado en
http://www.argo.es/~jcea/irc/olimpo3.htm, al final de la "To Do".

> ¿ El mero hecho de que proceda de una ejecucion
> anterior no recuperada es suficiente?

Una transacción NO COMPLETADA proveniente de un proceso que ya no existe
es, por definición, una transacción "zombie". Su proceso responsable ya
no existe, así que no puede ni hacer "commit" ni "rollback" de ella. Lo
mejor que se puede hacer es un "rollback" forzado. Osea, una
recuperación.

> ¿Y si esta ejecucion procede de digamos de un plazo temporal largo,
> habria que conservar todo lo posterior obligatoriamente o hay otros
> modos de discriminar la cuantia de almacenamiento?

Depende mucho de cómo funcione la base de datos, en especial en lo que
se refiere a los bloqueos. En berkeleyDB, por ejemplo, se usan bloqueos
en dos fases: en la primera sólo se obtienen locks; en la segunda sólo
se liberan locks (instantaneamente). Todo ello automático, claro. La
idea es que si una transacción modifica una página, haya un lock sobre
dicha página para evitar que transacciones "futuras" puedan leerla hasta
que la transacción original termine. No puedes leerla porque no sabes si
la transaccion original va a hacer más cambios o, incluso, si va a
sufrir un "rollback" y "desaparecer".

Vamos, un ACID (atomicidad, consistencia, independencia y "durabilidad")
clásico de toda la vida.

Teóricamente no necesitarías lo posterior. En la práctica estas cosas
hay que programarlas y deben funcionar bien, así que lo normal es que
solo se borre un fichero de "log" cuando a) es el más antiguo y b) todas
sus transacciones están resueltas. Obviamente al borrar un log, el punto
"a" se aplicaría al siguiente fichero.

Esto es lo que hace la Berkeley DB.

> Me imagino que algo asi se contemplara
> para evitar que haya exceso de logs, y por tanto de megas, para las
> recuperaciones futuras, cara a establecer horizontes temporales.

Tal y como está diseñado Olimpo, con toda la mala idea, cualquier
transacción en estado 5 indica un error que hay que solucionar. Sólo se
puede producir por un fallo del propio olimpo, del disco duro o del
servidor, así que la idea es que Olimpo, al arrancar, haga la
comprobación y la limpieza (esto lleva un par de segundos a lo sumo). En
ese momento, el problema que indicas desaparece.

> Lo comento porque si no hay otra manera, podria parecer hasta medio
> coherente, programar recuperaciones intencionadas en plazos menores

Sólo hay que hacer recuperaciones ante "casques". Los casques son
fácilmente detectables, porque un proceso "eterno" acaba de desaparecer
};-).

Un script simple podría ser

 while true
 do
   db_recover
   olimpo
 done

De hecho este script es el que he usado estos días, debido a los fallos
de Olimpo ocasionado por un bug de solaris que será tema de otro email
};-).

> En fin espero haberme medio expresado, y nada, si te parece relevante,
> nos cuentas un poco más acerca de esta "feature" del framework Olimpo.

El código de Olimpo es propietario, pero respondo preguntas medianamente
inteligentes y/o interesantes.

Sugiero que echeis un vistazo a http://www.sleepycat.com/, en concreto a
http://www.sleepycat.com/docs/index.html, y más concretamente
http://www.sleepycat.com/docs/reftoc.html, sobre todo la sección 9.

No mireis la sección 10, no sea que alguien sufra un exceso de
endorfinas cerebrales.

PS: "endorfina": Busca en Google :-)
 
-- 
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