Re: Replicacion

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