[pgsql-ayuda] Re: Base SQL distribuida

La Mancha de la Calabaza que Ladra twisted the bytes to say:

>> A mi me parece que la implementación "básica" de la base de datos no
>> es el problema. El problema fuerte es el manejo de transacciones y
>> rollback en caso de que una máquina no pueda hacer commit. Y las
>> fallas potenciales en comunicación: ¿qué haces si una de tus máquinas
>> no contesta? ¿Cuanto tiempo esperas? ¿Qué pasa si se quedó a medias?
>> ¿haces rollback a toda la transacción en todas las máquinas? La
>> máquina que se quedó desconectada ¿hace rollback o sigue intentando?
>> Que pasa si se "cayó" y cuando regresa nota que tiene una transacción
>> a medias y recibe notificación nuevamente de hacerla de nuevo,

La Mancha> Muy buen punto. Ya había llegado a la conclusión de que no se puede
La Mancha> hacer por medio de hooks, sino que a fuerza se tiene que implementar
La Mancha> sobre un protocolo de comunicación anterior al API de Postgres. Es
La Mancha> decir, postgres no tiene porque enterarse de que está replicando.

No del todo. Hay algo que creo no has considerado: ¿qué pasa si dos
máquinas quieren modificar el mismo renglón al mismo tiempo? Postgres
maneja transacciones. Se require que el usuario utilice transacciones
para este tipo de bases de datos, para que en caso de que haya
colisiones sea posible hacer rollback hasta un punto en que haya
consistencia de datos.

La Mancha> Ahora, creo que no tiene que haber rollback en ninguna de las
La Mancha> copias. Es decir, el protocolo debe de detectar que una de las
La Mancha> máquinas no aceptó la transacción, entonces la encola para esa máquina
La Mancha> y la siguiente vez que puede enviarle algo, le envía todo lo que se
La Mancha> quedó en la cola. Pero en ningún caso el motor de la BD de las
La Mancha> máquinas toma la decisión.

Si las bases de datos permiten la caída de sus canales de
comunicación esto se vuelve un poco truculento. Piensen en el peor de
los casos: A y B pierden comunicación. A modifica el dato x. B
modifica x y en función a su valor, 'y'. Resulta que A tiene prioridad
sobre la modificación (quien tiene prioridad lo debe decidir el
scheduler). Entonces el valor de 'y' es "bogus".

La solución más simple es implementar un sistema en que no se permita
"caida" de la línea. Sí se cae, la base se puede leer, pero no
modificar. Cuando se modifica, se fuerza un "lock" al renglón en todas
las bases antes de proceder (este es el escenario que la base de datos
utiliza en que cada proceso diferente es como una máquina remota, por
así decirlo).

De otra forma, cuando B regresa, debe de revistar su bitácora y
compararla con la "maestra" (aquí hay otro bonche de problemas
--¿quien decide?) y tiene que hacer rollback a y y luego a x. Después
reaplicar los cambios que la maestra bitácora especiqueó. Y si hubo
más cambios que no choquen con el resto de la base de datos --digamos
que B modificó z sin necesitar algo más-- entonces z se
propaga. ¿Tricky? No :) Ahora imagínate lo difícil que sería para el
usuario entender como programar con locks distribuídos, si de por si
no usa locales :)

La Mancha> Se me ocurre que como postgres por default escucha en el puerto 5432,
La Mancha> o bien se cambia el puerto y se pone al demonio del coyote a escuchar
La Mancha> ese puerto o bien el coyote escucha otro y envía al de postgres por el
La Mancha> usual.

Sip. Esta es buena solución. Un demonio que se encargue de la
comunicación y demás.

La Mancha> El problema se reduce a que el protocolo del coyote debe de tener la
La Mancha> previsión de arbitrar a quién le replica. Puesto de otra manera, puede
La Mancha> ser que haya un coyote alfa (como los lobos) que coordine el replique
La Mancha> a los demás o que cada coyote le replique a uno en particular y sólo
La Mancha> sea uno el que recibe todos los queries (otro coyote alfa).

En esta línea, lo importante también es decidir si cualquier máquina
puede ser utilizada para hacer modificaciones o sólo puede consultar y
las modficaciones se hacen en una "alfa" que replique a las demás. Es
decir, sólo una acepta cambios que después envía a todos. Este es un
protocolo más simple.

La Mancha> Bueno, se me ocurre que es más fácil ir por este lado que por el de
La Mancha> meterle mano a postgres para que él sea quién ande replicando. De ahí
La Mancha> el nombre de coyote.

Totalmente de acuerdo. Puede programarse encima de postsgres y es
solución más modular.

La Mancha> El primer mensaje de Kovalski lo perdí y por eso no contesté, pero me
La Mancha> interesa el asunto. Igual y sería bueno discutirlo sólo en la lista de
La Mancha> postgres o crear una para el proyecto.

Debe haber literatura científica al respecto --un bonche-- voy a ver
si encuentro algo por mi lado.

La Mancha> Salud y anarquía.

Idem y nos leemos,

La Mancha> --
La Mancha> La Mancha, http://dania.matem.unam.mx/~mancha
La Mancha> casa://depto5.AvRevolucion1761.SanAngel.df.mx/~mancha
La Mancha> ring://5550-2547.df.telmex.com.mx/~pedir.por.mancha
La Mancha> chamba://cubo-120.matem.cu.unam.mx/~mancha
La Mancha> rechamba://5622-4484.df.telmex.com.mx/~pedir.por.el.chalan

--
Daniel M. German "A first-rate laboratory is one in
which mediocre scientists can produce
Patrick Maynard Stuart Blackett ->outstanding work"
http://csgwww.uwaterloo.ca/~dmg/home.html
dmg(at)csg(dot)uwaterloo(dot)ca

--------- Pie de mensaje -------------------------------------------
Archivo historico: http://tlali.iztacala.unam.mx/maillist/pgsql-ayuda
Cancelar inscripcion:
mail to: majordomo(at)tlali(dot)iztacala(dot)unam(dot)mx
text : cancelacion pgsql-ayuda