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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-es-ayuda by date

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