Re: replicacion

>
> Buenas tardes a todos y gracias de antemano.
> Al grano... hace un tiempo estoy tratando de implementar replicación
> multimaestro en postgresql usando una porción de pyreplica y un
> demonio propio.
> El procedimiento inicia con el registro en una cola (tabla) de las
> transacciones en forma de sentencia sql a nivel de fila (trigger for
> each row) de las tablas a replicar. Luego un demonio (asíncrono,
> autónomo e independiente) ejecuta en forma secuencial y transaccional
> estas sentencias en cada nodo, hasta aqui nada nuevo.
> Para mantener la integridad debo tomar de la cola lo que esté
> "commiteado" o esperar aquello que esté pendiente sobre ella
> consultando pg_locks, sin embargo existe un lapso de tiempo entre la
> visibilidad de los bloqueos en pg_locks y su visibilidad efectiva en
> la cola (visible con select * from...) lo que provoca una
> desincronización en el orden de estas transacciones.
> La consulta que uso para obtener las transacciones pendientes sobre la
> cola es la siguiente:
>
> select b.transactionid::text::bigint
> from pg_locks a
> join pg_locks b
> on b.pid = a.pid
> where b.locktype = 'transactionid'
> and a."mode" = 'RowExclusiveLock'
> and b.transactionid::text::bigint < $1
> and a.relation = 'tabla_con_registros_a_replicar'::regclass::oid
>
> Donde $1 es el id de la primera transacción a replicar obtenida
> mediante un "select" en la cola, con lo que debería obtener las
> transacciones pendientes sobre la cola anteriores a él, pero no
> siempre es así.
> Actualmente el efecto de esto es que el demonio principal se encuentra
> en la cola con una transacción "vieja" no replicada por lo que se
> detiene, hasta que efectúo la replicación de ella en forma manual,
> evento que sucede una vez a la semana como media. Ello con una tasa de
> replicación que asciende a 25 registros por segundo como media para
> cada nodo.
> Intenté quitarle la restricción para "locktype" y para "mode" (para
> que considere incluso los "select") pero tampoco funcionó.
> Entonces, sabe alguien si existe alguna vista o función o cualquier
> mecanismo para obtener un conjunto de datos de una tabla garantizando
> que si no se detecta ninguna transacción pendiente sobre esa tabla
> entonces ese conjunto de datos está realmente actualizado ?
> Porque pyreplica ? hace unos 5 años invertí mucho tiempo buscando y
> evaluando soluciones para replicación multimaestro pero al año terminé
> usando pyreplica y creando mi propio demonio, todo ello por la
> simplicidad y flexibilidad al implementarlo en una base de datos cuyo
> diseño casi no puedo "retocar".
> Porque multimaestro ? tengo 12 almacenes distribuidos en largas
> distancias que requieren compartir información lo antes posible (...)
> pero en caso de "caída" de nodos o de enlaces, cada uno debe seguir
> operando en forma autónoma y sincronizar automáticamente al momento de
> estar disposible nuevamente.
> En este momento tengo en producción la versión 8.3.6 de postgresql y
> por la gran masa de datos y procedimientos almacenados veo difícil la
> migración a corto plazo, pero si la solución pasa por migrar entonces
> tendré que hacerlo.
>
> Gracias
>
Fernando, disculpa muy largo tu texto por lo que hay aspectos que no me
quedan claro.

¿por que no usas algo de lo ya hecho para esos caso? Ejemplo bucardo,
SysmtrisDS

¿Estas claro que la replicación Maestro-Maestro es muy complicad de mantener?

Piensa en armar un esquema con Slony-I, algo de eso nos enseño Alvaro una
vez y parece interesante ese planteamiento... dado los royos de la opción
que has escogido.

Saludos,
Gilberto Castillo
La Habana, Cuba