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: AyudaPostgres <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Replicacion
Date: 2005-02-26 11:33:11
Message-ID: 42205E77.4070906@soft-com.es (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Hola Carlos,

cbeltran escribió:
> Oswaldo,
> 
> 
> La base de datos tiene diseño identico en los servidores maestros y en el
> servidor central y las tablas se clasificaron asi:
> 
> - Tablas maestras puras. (No son replicadas ni sincronizadas)
> - Tablas maestras operativas. (SI son replicadas y SI son sincronizadas)
> - Tablas de movimiento. (SI son replicadas y NO son sincronizadas)
> - Tablas de edicion. (Practicamente temporales y No son replicadas ni
> sincronizadas)
> 

No entiendo muy bien la diferenciación que haces entre replicadas y
sincronizadas, me imagino que te refieres a que las tablas replicadas
solo viajan en un sentido y las sincronizadas en ambos.


> Para poder identificar en que servidor (Oficina) se ingreso una linea de
> cualquier tabla se estableció lo siguiente (Una tabla por ejemplo terceros)
> luce asi:
> 
> CREATE SEQUENCE terceros_id_seq start  XX0000001 increment 1 maxvalue
> 999999999 minvalue 000000001  cache 1 ;
> CREATE TABLE terceros (
>       terceros_id integer DEFAULT nextval('terceros_id_seq'::text) NOT NULL,
>       tercero integer NOT NULL,
>       digito_verificacion char(1),
>       etc...
> Y terceros_id es PRIMARY KEY con XX prefijo del serial y así evitando el
> choque en el servidor central, además de identificar el server que hizo el
> insert original de la linea.
> 

En mi caso utilizo dos tenicas dependiendo de la tabla: para los 
movimientos una clave primaria compuesta por dos campos, el 
identificador y el numerador, y para los maestros establezco los rangos 
que puede utilizar cada base de datos.


>  ....
> Con este diseño no se necesita almacenar en el control los contenidos de esa
> linea sino unicamente el id correspondiente. Por supuesto se presentan casos
> tales como sucesivos updates en el control acumulados que al replicar con el
> primero hubiera bastado. Otro caso puede ser que un update precedido de un
> delete, al replicar, ya no encuentre la línea y se considera un update dummy
> para que posteriormente si se efectue en el servidor central el delete y
> bueno, podrían haber otros casos
> 
> Con este control generandose en los servers maestros el servidor central con
> hilo de ejecucion por server esta continuamente replicando al central y
> sincronizando. La estrategia de replicado es obtener la operacion (D/U/I) y
> con el nombre de cada tabla y el id de la línea de esa tabla
> (linea_tabla_replica_id) en orden de generacion del control_replica se
> obtiene el contenido de dicha linea del server maestro y se hace la
> respectiva operacion en el central para luego borrar del server central la
> línea de control. Las operaciones imposibles de llevar a cabo en el server
> central se escriben en un archivo de log tambien por hilo de ejecucion
> borrando también el control. Esta estrategia permite asegurar que en caso de
> interrupcion de conexiones la linea de control de un momento dado sin borrar
> repite la operacíon en servidor central sin ningun riesgo de perdida de
> informacion.
> 


En un principio pense en un diseño parecido a este, guardar unicamente 
la tabla y el identificador del registro afectado (por cierto la 
solución del update dummy es muy buena) manteniendo en el servidor 
central una base de datos consolidada. Tambien consideré otra técnica 
que utilizan algunos sistemas de replicación basada en guardar las 
sentencias SQL (excepto selects) para reproducirlas en las bases de 
datos remotas, pero los Delete y Update que afectan a grupos de 
registros me dan un miedo terrible.

Al final para mi proyecto me incliné por la opción de empaquetar y 
guardar el registro completo por los motivos que te explico:

Necesito un sistema mas o menos flexible, en el que cada base de datos 
tenga su propia frecuencia y características de replicacion, es decir, 
el sistema deberia contemplar la posibilidad que unas bases de datos se 
comunicaran con la central esporádicamente, mientras que otras lo 
hicieran de forma continua, que unas sincronizaran maestros y 
movimientos y otras solo parte de estos. Por ejemplo, una delegación 
tendria una frecuencia de replica alta sincronizando maestros y 
movimientos, mientras que el portatil de un comercial tendria una 
frecuencia baja y se limitaria a sincronizar el estado de los pedidos de 
sus clientes.

Debido a la posible movilidad de las bases de datos las comunicaciones 
deben de ser siempre activadas por las base de datos remotas (salvo 
excepciones), esto provoca que el servidor central desconozca cuando se 
va a proceder a la sincronización de estas.

Para mantener de una forma clara el estado de replica de cada una de 
estas bases de datos tendria que mantener dentro de el servidor central 
una imagen del estado de cada una de las bases de datos remotas. Cuando 
la cantidad de bases de datos llegara a ser alta se complicaria 
enormenente el mantenimiento de estas.

Para simplificar esto pensé en el sistema de empaquetamiento de los 
datos. Esta estructura del servidor de replicacion no necesitaria 
modificacion cuando necesitara realizar cambios en la aplicacion (añadir 
o quitar campos, tablas, etc).

Otro factor que tengo en cuenta es la posibilidad de aplicar el mismo 
sistema (con el minimo de modificaciones posible) a otros proyectos.

No hemos comentado hasta ahora el problema de la propagación de los 
cambios en la estructura de las bases de datos replicadas, ¿Que haces 
cuando necesitas añadir un nuevo campo a una tabla, o utilizar una tabla 
nueva?

Tampoco hemos comentado la resolución de conflictos. ¿Que haces cuando 
modifican en mismo registro simultáneamente en dos bases distintas?

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


In response to

Responses

pgsql-es-ayuda by date

Next:From: nathaly villacisDate: 2005-02-26 12:58:54
Subject: Ayuda con Postgress bajo windows........
Previous:From: gonzalo sáenzDate: 2005-02-26 00:13:45
Subject: Re: Ayuda Consumo de Espacio

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