[pgsql-ayuda] Re: Base SQL distribuida

>A mi me parece que la implementacin "bsica" de la base de datos no
>es el problema. El problema fuerte es el manejo de transacciones y
>rollback en caso de que una mquina no pueda hacer commit. Y las
>fallas potenciales en comunicacin: qu haces si una de tus mquinas
>no contesta? Cuanto tiempo esperas? Qu pasa si se qued a medias?
>haces rollback a toda la transaccin en todas las mquinas? La
>mquina que se qued desconectada hace rollback o sigue intentando?
>Que pasa si se "cay" y cuando regresa nota que tiene una transaccin
>a medias y recibe notificacin nuevamente de hacerla de nuevo,

Muy buen punto. Ya haba llegado a la conclusin de que no se puede
hacer por medio de hooks, sino que a fuerza se tiene que implementar
sobre un protocolo de comunicacin anterior al API de Postgres. Es
decir, postgres no tiene porque enterarse de que est replicando.

Ahora, creo que no tiene que haber rollback en ninguna de las
copias. Es decir, el protocolo debe de detectar que una de las
mquinas no acept la transaccin, entonces la encola para esa mquina
y la siguiente vez que puede enviarle algo, le enva todo lo que se
qued en la cola. Pero en ningn caso el motor de la BD de las
mquinas toma la decisin.

Digamos que tienes cuatro mquinas sirviendo la base: A, B, C y D. Al
Coyote (el programa encargado de pelar las transacciones y
replicarlas) le llega una solicitud, que puede ser una consulta. En
este caso la manda a las cuatro y regresa lo que conteste primero, sin
importar cual mquina. Ahora digamos que le llega una solicitud de
insercin, entonces manda a A, a B, a C y a D. Digamos que C no
responde o no regresa respuesta, o regresa un error, entonces el
coyote agarra y encola el query para C nada ms y sigue pelando
transacciones. Esto se repite hasta que C comienza a responder de
nuevo y entonces el coyote la pone al da con todo lo que qued
encolado. Mientras tanto, obviamente, las consultas no las manda a C.

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

El problema se reduce a que el protocolo del coyote debe de tener la
previsin de arbitrar a quin le replica. Puesto de otra manera, puede
ser que haya un coyote alfa (como los lobos) que coordine el replique
a los dems o que cada coyote le replique a uno en particular y slo
sea uno el que recibe todos los queries (otro coyote alfa).

Bueno, se me ocurre que es ms fcil ir por este lado que por el de
meterle mano a postgres para que l sea quin ande replicando. De ah
el nombre de coyote.

El primer mensaje de Kovalski lo perd y por eso no contest, pero me
interesa el asunto. Igual y sera bueno discutirlo slo en la lista de
postgres o crear una para el proyecto.

Salud y anarqua.

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