[pgsql-ayuda] Re: Base SQL distribuida

[La Mancha de la Calabaza que Ladra]

>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, 

Muy buen punto. Ya había llegado a la conclusión de que no se puede
hacer por medio de hooks, sino que a fuerza se tiene que implementar
sobre un protocolo de comunicación 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
máquinas no aceptó la transacción, entonces la encola para esa máquina
y la siguiente vez que puede enviarle algo, le envía todo lo que se
quedó en la cola. Pero en ningún caso el motor de la BD de las
máquinas toma la decisión.

Digamos que tienes cuatro máquinas 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 máquina. Ahora digamos que le llega una solicitud de
inserción, 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 más y sigue pelando
transacciones. Esto se repite hasta que C comienza a responder de
nuevo y entonces el coyote la pone al día 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 envía al de postgres por el
usual.

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

Bueno, se me ocurre que es más fácil ir por este lado que por el de
meterle mano a postgres para que él sea quién 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 sería bueno discutirlo sólo en la lista de
postgres o crear una para el proyecto.

Salud y anarquía.

--
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@tlali.iztacala.unam.mx
text   : cancelacion pgsql-ayuda