Skip site navigation (1) Skip section navigation (2)

Re: Replicacion

From: Oswaldo Hernández <listas(at)soft-com(dot)es>
To: cbeltran <cbeltran(at)roldan(dot)net>
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Replicacion
Date: 2005-02-23 12:09:35
Message-ID: 421C727F.6070101@soft-com.es (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
cbeltran escribió:
> Oswaldo
> 
> La replica desde varios maestros y/o la sincronización hacia los demás
> maestros de ciertas tablas de una base de datos es de mi especial interes.
> La solución en producción esta diseñada con un servidor central que
> consolida (replica) los movimientos de los 14 servidores maestros
> independientes y actualiza (sincroniza) los demas servidores excepto el
> servidor fuente de la operacion. El diseño esta hecho con base en triggers y
> funciones que almacenan en una tabla de control las operaciones(I/U/D) de
> cada UNA las tablas en replica en cada uno de los servidores maestros y otro
> triguer que almacenan en una tabla de control el movimiento de las tablas
> que van a ser sincronizados. El desarrollo se hizo a la medida de nuestras
> necesidades y con los tips brindados por Alvaro y Manuel. E siguiente link
> muestra la pregunta correspondiente al ultimo escollo antes de salir a
> produccion.
> 
> http://archives.postgresql.org/pgsql-es-ayuda/2004-11/msg00442.php
> 
> 


Hola Carlos,

El diseño que estoy preparando es parecido al tuyo.

Cada tabla de la base de datos incorpora un trigger que en las 
operaciones de Insert, Update o Delete comprueba las reglas de esta 
tabla y si se cumplen añade un registro a la tabla de envíos (cola de 
salida).

Este tabla (cola de salida) contiene: un autonumerico para establecer el 
orden de salida, un identificador de la base de datos origen, el nombre 
de la tabla, la operación realizada (I/U/D), y un campo  bytea o blob 
(todavia por definir) que contiene todos los datos del registro 
enpaquetados.

En este punto tengo dos temas a solucionar:

1. Necesito una funcion que empaquete un registro entero de datos dentro 
de un solo campo, y otra funcion que realice la operación inversa. He 
estado intentándolo con plpgsql y creo que no es posible de esta forma, 
pero imagino que no tendré problemas para hacerlo con plpython (todavía 
no lo he intentado). También sobre esto tendré que hacer pruebas sobre 
el rendimiento.

2. Como esta tabla contiene los datos que han de ser modificados en el 
resto de las bases de datos, me gustaría que además del orden en el que 
han de ser actualizados, contuviera también un identificador de la 
transacción. La finalidad de esto es que todos los datos que han sido 
modificados en una misma transaccion se actualicen en el resto de bases 
de datos también dentro de una misma transaccion, (soy bastante 
pesimista y siempre supongo que las comunicaciones se van a romper en el 
momento mas inesperado). De esta forma me aseguraria la integridad de 
los datos si ocurriera algún problema.
No se si esto va a ser posible, por lo menos de una forma sencilla. :(


Un proceso en background examina periódicamente esta tabla de salida, 
conecta con la base de datos central (centro de distribución)  y copia 
estos datos en en una tabla de entrada, una vez hecho esto toma los 
datos que tiene preparados para ella en el centro de distribución, y los 
actualiza en la base de datos local comprobando posibles conflicos y/o 
rechazos.

La estructura de este centro de distribucion esta basada en colas, una 
tabla general de entrada, donde todas las bases de datos replicadas 
insertan sus modificaciones, y una cola o tabla de salida para cada base 
de datos replicada. La tabla de entrada cotiene un trigger que en el 
momento de la insercion de un registro por una de las bases de datos 
replicadas, genera un registro de salida para cada una de las demás.

Sobre el transporte de datos entre unas bases de datos a otras, mi idea 
es hacerlo de forma directa, mediante un proceso que conecte 
directamente la base de datos replicada al centro de distribucón, aunque 
esto suponga posibles problemas de seguridad al tener este centro 
escuchando directamente por internet (tendria que configurar las 
conexines ssl, y cualquier otra cosa que se me ocurra para ponerselo 
dificil a los "curiosos").


En cuanto al problema de rebotes que comentas que tuviste, lo he 
solucionado incluyendo, mediante un trigger, en el registro de datos un 
identificador de la base de datos que ha generado o modificado el 
registro, el trigger que envia los datos para ser replicados simplemente 
ignora los registros que no han sido generados localmente.


Esta es la idea básica de mi diseño de replicación, evidentemente ademas 
de esto establece infinidad de reglas para evitar posibles conflictos en 
la lógica de la aplicación.

Agradeceria cualquier comentario sobre ella.

Saludos,

-- 
*****************************************
Oswaldo Hernández
oswaldo(at)soft-com(dot)es
*****************************************

In response to

Responses

pgsql-es-ayuda by date

Next:From: Carlos PalaciosDate: 2005-02-23 13:10:36
Subject: como me puedor dar de baja en la lista por dios
Previous:From: sandrigo.lezcano@gmail.comDate: 2005-02-23 12:06:28
Subject: Re: initdb: failed

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group