Re: Replicacion

Hola lista , me gustaria que alguien hablara un poco de la replicacion de bd , asi como las herramientas y a lo mojor ejemplos practico, yo creo que a muchos de la lista le interesa este tema

De antemano gracias

Saludos!

No sé si esta lista es el lugar adecuado ¿qué opina la gente? ¿qué
opina el moderador?
(La verdad es que slony1 promete mucho como proyecto y no hay nada de
información en nuestra lengua).

On Fri, 18 Feb 2005 09:40:38 +0100, Roberto Cesar Najera <rob(at)rtp(dot)gob(dot)mx> wrote:
>
> Hola lista , me gustaria que alguien hablara un poco de la replicacion de bd
> , asi como las herramientas y a lo mojor ejemplos practico, yo creo que a
> muchos de la lista le interesa este tema
>
> De antemano gracias
>
> Saludos!

--
Juanky Moral
"Tendré que moverme más rápido: el horizonte brilla eléctrico."
(Horizonte Eléctrico - www.losdeltonos.com )

On Fri, 18 Feb 2005 19:16:52 +0100, Juanky Moral <juanky(dot)moral(at)gmail(dot)com> wrote:
> No sé si esta lista es el lugar adecuado ¿qué opina la gente?
>
Slony-1 esta tan relacionado a postgres que no creo que alguien se
oponga. Yo no lo he probado asi que mejor me callo.

> ¿qué opina el moderador?
>
Tenemos moderador en la lista? No lo conozco, o nunca me dijeron que
era moderador.

> (La verdad es que slony1 promete mucho como proyecto y no hay nada de
> información en nuestra lengua).
>
No solo promete se que mucha gente usa Slony con mucho exito.

atentamente,
Jaime Casanova

Roberto Cesar Najera escribió:
> Hola lista , me gustaria que alguien hablara un poco de la replicacion
> de bd , asi como las herramientas y a lo mojor ejemplos practico, yo
> creo que a muchos de la lista le interesa este tema
>

Creo que es un tema muy interesante, y que seria muy provechoso
compartir opiniciones sobre la replicación, especialmente en escenarios
de multiples masters.

Saludos,

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

On Fri, 18 Feb 2005 22:16:00 -0500, Jaime Casanova wrote
[...]
> > ¿qué opina el moderador?
> >
> Tenemos moderador en la lista? No lo conozco, o nunca me dijeron que
> era moderador.

Si tenemos, por lo menos, si mal no recuerdo a la lista la moderan Alvaro
Herrera y Martín Marquéz. Saludos...

-------------------------------------------
Sebastián Villalba
sebastian(at)fcm(dot)unc(dot)edu(dot)ar
-------------------------------------------

On Mon, Feb 21, 2005 at 08:31:49AM -0300, Sebastián Villalba wrote:
> On Fri, 18 Feb 2005 22:16:00 -0500, Jaime Casanova wrote
> [...]
> > > ¿qué opina el moderador?
> > >
> > Tenemos moderador en la lista? No lo conozco, o nunca me dijeron que
> > era moderador.
>
> Si tenemos, por lo menos, si mal no recuerdo a la lista la moderan Alvaro
> Herrera y Martín Marquéz. Saludos...

Moderamos solo aquello que viene de gente no suscrita. En rigor, somos
mas "mantenedores" que moderadores.

Yo opino que el tema de Slony-I cae dentro del topico de esta lista, en
todo caso.

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"Oh, great altar of passive entertainment, bestow upon me thy discordant images
at such speed as to render linear thought impossible" (Calvin a la TV)

On Sat, Feb 19, 2005 at 09:33:11AM +0100, Oswaldo Hernández wrote:
> Roberto Cesar Najera escribió:
> >Hola lista , me gustaria que alguien hablara un poco de la replicacion
> >de bd , asi como las herramientas y a lo mojor ejemplos practico, yo
> >creo que a muchos de la lista le interesa este tema
> >
>
>
> Creo que es un tema muy interesante, y que seria muy provechoso
> compartir opiniciones sobre la replicación, especialmente en escenarios
> de multiples masters.

Solo te puedo decir que el problema general de multiples masters es muy
dificil de tratar, y si crees que vas a ganar rendimiento usando una
herramienta generica para eso, realmente desconoces el tema de una forma
escandalosa ;-)

Creo que ya lo comente: el nuevo pgpool entiende de Slony-I, y la idea
es que envia consultas de solo lectura a las replicas de solo lectura, y
las otras al maestro. A mi me parece una cosa muy potente y vale la
pena investigarlo.

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"There is evil in the world. There are dark, awful things. Occasionally, we get
a glimpse of them. But there are dark corners; horrors almost impossible to
imagine... even in our worst nightmares." (Van Helsing, Dracula A.D. 1972)

Alvaro Herrera escribió:
> On Sat, Feb 19, 2005 at 09:33:11AM +0100, Oswaldo Hernández wrote:
>
>>Roberto Cesar Najera escribió:
>>
>>>Hola lista , me gustaria que alguien hablara un poco de la replicacion
>>>de bd , asi como las herramientas y a lo mojor ejemplos practico, yo
>>>creo que a muchos de la lista le interesa este tema
>>>
>>
>>
>>Creo que es un tema muy interesante, y que seria muy provechoso
>>compartir opiniciones sobre la replicación, especialmente en escenarios
>>de multiples masters.
>
>
> Solo te puedo decir que el problema general de multiples masters es muy
> dificil de tratar, y si crees que vas a ganar rendimiento usando una
> herramienta generica para eso, realmente desconoces el tema de una forma
> escandalosa ;-)

Se de sobra que es un tema harto difícil de tratar con herramientas
genéricas, puesto que la definición de reglas y resolución de conflictos
depende de cada aplicación.

En este momento estoy trabajando en el diseño de una aplicación que
incluye sistema de replicación asíncrona con múltiples masters, por eso
hablo de compartir opiniones con otros que cambien estén trabajando en
cosas similares. El compartir conocimiento es algo beneficioso para todos.

Saludos,

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

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

Si deseas detalles adicionales de diseño me avisas.

Carlos Beltran V.
Roldan SIA SA Bogota, Colombia.

----- Original Message -----
From: "Oswaldo Hernández" <listas(at)soft-com(dot)es>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Tuesday, February 22, 2005 4:13 AM
Subject: Re: [pgsql-es-ayuda] Replicacion

> Alvaro Herrera escribió:
> > On Sat, Feb 19, 2005 at 09:33:11AM +0100, Oswaldo Hernández wrote:
> >
> >>Roberto Cesar Najera escribió:
> >>
> >>>Hola lista , me gustaria que alguien hablara un poco de la replicacion
> >>>de bd , asi como las herramientas y a lo mojor ejemplos practico, yo
> >>>creo que a muchos de la lista le interesa este tema
> >>>
> >>
> >>
> >>Creo que es un tema muy interesante, y que seria muy provechoso
> >>compartir opiniciones sobre la replicación, especialmente en escenarios
> >>de multiples masters.
> >
> >
> > Solo te puedo decir que el problema general de multiples masters es muy
> > dificil de tratar, y si crees que vas a ganar rendimiento usando una
> > herramienta generica para eso, realmente desconoces el tema de una forma
> > escandalosa ;-)
>
> Se de sobra que es un tema harto difícil de tratar con herramientas
> genéricas, puesto que la definición de reglas y resolución de conflictos
> depende de cada aplicación.
>
> En este momento estoy trabajando en el diseño de una aplicación que
> incluye sistema de replicación asíncrona con múltiples masters, por eso
> hablo de compartir opiniones con otros que cambien estén trabajando en
> cosas similares. El compartir conocimiento es algo beneficioso para todos.
>
> Saludos,
>
> --
> *****************************************
> Oswaldo Hernández
> oswaldo(at)soft-com(dot)es
> *****************************************
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 9: el optimizador ignorará el uso de recorridos de índice si los
> tipos de datos de las columnas no coinciden

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

Oswaldo,

Los aspectos que mencionas sobre "seguridad al tener este centro escuchando
directamente por internet", definicion agrupada de gran cantidad de
movimientos provenientes de un servidor en una misma "transaccion en el
servidor central", mas otros que mencionas fueron objeto de controversia en
nuestro primer diseño y por supuesto estamos pendientes de evolucionar
nuestro esquema de replica/sincronizacion para un siguiente release. Me
parece importante cruzar estos conceptos para efectos de mejora y por lo
tanto voy a plantear el esquema con mayor detalle.

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)

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.

Las tablas maestras operativas y de movimiento (replicables) residen en una
tabla llamada tablas_replica con la siguiente estructura:

CREATE SEQUENCE tablas_replica_id_seq start 180000001 increment 1 maxvalue
999999999 minvalue 000000001 cache 1 ;
CREATE TABLE tablas_replica (
tablas_replica_id integer DEFAULT nextval('tablas_replica_id_seq'::text)
NOT NULL,
tabla_nombre_replica character(90) NOT NULL,
CONSTRAINT pk_tablas_replica PRIMARY KEY (tablas_replica_id)
);

de tal manera que un trigger para la tabla terceros inserta una linea en la
tabla control_replica de la siguiente estructura:

CREATE SEQUENCE control_replica_id_seq start 180000000000000001 increment 1
maxvalue 999999999999999999 minvalue 000000000000000001 cache 1 ;
CREATE TABLE control_replica (
control_replica_id bigint DEFAULT
nextval('control_replica_id_seq'::text) NOT NULL,
tablas_replica_id integer NOT NULL,
linea_tabla_replica_id bigint NOT NULL,
operacion character(6),
CONSTRAINT pk_control_replica PRIMARY KEY (control_replica_id),
CONSTRAINT fk_tablas_replica_id1 FOREIGN KEY (tablas_replica_id)
REFERENCES tablas_replica(tablas_replica_id) ON UPDATE CASCADE ON DELETE
CASCADE
);

Dicho trigger es:

CREATE FUNCTION "rp_terceros"() RETURNS TRIGGER AS '
BEGIN
IF TG_OP = ''DELETE'' THEN
INSERT INTO control_replica (tablas_replica_id,
linea_tabla_replica_id, operacion) VALUES (180000002,OLD.terceros_id,
TG_OP);
RETURN OLD;
END IF;
IF TG_OP = ''INSERT'' THEN
INSERT INTO control_replica (tablas_replica_id,
linea_tabla_replica_id, operacion) VALUES (180000002,NEW.terceros_id,
TG_OP);
RETURN NEW;
END IF;
IF TG_OP = ''UPDATE'' AND OLD.terceros_id = NEW.terceros_id THEN
INSERT INTO control_replica (tablas_replica_id,
linea_tabla_replica_id, operacion) VALUES (180000002,NEW.terceros_id,
TG_OP);
RETURN NEW;
END IF;
END;
' LANGUAGE 'plpgsql';
CREATE TRIGGER rp_terceros BEFORE INSERT OR UPDATE OR DELETE ON terceros FOR
EACH ROW EXECUTE PROCEDURE rp_terceros();

Es decir tablas_replica_id, para el caso de la tabla "terceros" es 180000002
y linea_tabla_replica_id almacena terceros_id que es el PRIMARY KEY de la
línea objeto de la operacion.

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.

El esquema de sincronizacion es similar pero con un control adicional de
linea a sincronizar por server.

Carlos Beltran V.
Roldan SIA SA Bogota, Colombia.

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

Hola Carlos,

cbeltran escribió:
> Oswaldo,
>
> Interesante y enriquecedor este intercambio de conceptos.
>
Si.

>
>
>
> En este diseño todos los aplicativos son WEB (con capa de logica en PHP), y
> para operar siempre los usuarios deben alcanzar la IP (via
> intranet/extranet/internet) del servidor maestro y autenticarse en el
> servidor donde tienen su escritorio virtual de trabajo. El servidor central
> solo es de consulta (data consolidada) y para actividades de gestion y
> control. De tal manera que la base de datos central es la union de todas las
> bases de datos maestras (las que realmente registran la operacion
> distribuidamente).
>

Por lo que entiendo de esto, utilizas un sistema mixto, utilizas una
conexion directa a la base de datos consolidada para las consultas, y
grabais las operaciones en las bases locales para sincronizarlas
posteriormente.

>
> En efecto, cuando cambian las tablas maestras puras. (No son replicadas ni
> sincronizadas) y las demas, los alter y la respectiva inicializacion se esta
> haciendo por server y es tediosa. Esta situacion tiende a disminuir a medida
> que el sistema obtenga mayor estabilidad.
>
La propagacion de los cambio de estructura es un tema que me preocupa
mucho, puesto que el objetivo de mi proyecto es la instalación en varios
clientes, cada un son su respectivo sistema de sincronización. Me
gustaría encontrar un sistema de realizarlo de forma automática para
evitar los problemas que surgen al realizarlo manualmente.

> Se esta implementando una sincronizacion de tablas maestras puras para que
> el administrador opere en el servidor central y se sincronice a los servers
> maestros (Estos cambios son poco frecuentes).
>
> Cuando una linea de una tabla replicable y sincronizables es modificada casi
> simultaneamente en efecto queda vigente el ultimo cambio efectuado replicado
> y sincronizado. Estas tablas las hemos llamado tablas maestras operativas y
> son aquellas que deben ser absolutamente iguales en todos los servers y la
> politica para el manejo de esta informacion es de confirmar cada uno de los
> datos haciendo enfasis a los usuarios sobre la calidad de dicha informacion
> y la disponibilidad de ese ingreso o modificacion a nivel nacional. Para
> paliar esta situacion se tiene en el servidor central, hilos de ejecucion
> independientes para cada servidor (minimizando el tiempo de
> replica/sincronizacion) y por lo tanto este conflicto. Hay otros conflictos
> como por ejemplo los terceros que tienen un numero de identificacion unico y
> que justo simultaneamente se creen (poco probable pero posble) en dos
> servers maestros el primero que sincronice queda en el servidor central y
> sus posibles movimientos que directamente o indirectamente referencien (via
> foreign key) a dicha linea de terceros. Para estos casos cuando el servidor
> central trate de replicar dicha linea o las lineas referenciadas dan error y
> se registran en el log, que es administrado manualmente y el choque a suvez
> arreglado manualmente. Indudablemente este aspecto esta siendo analizado
> para generar una solucion a este conflicto automaticamente y ademas estamos
> averiguando esquemas teoricos que minimicen dicho riesgo.
>

El tema de los conflictos creo que es el meollo de un sistema de
replicación master-master. En mi caso, no basta con dar prioridad a la
modificación mas reciente, sino que me puedo encontrar con casos en que
esto no es válido. Por ejemplo, en una delegación se modifica una
operación, mientras tanto esa misma operación se cierra o bloquea en la
central, cuando llega la modificación a la central, esta se encuentra
con que está cerrada, y aunque inicialmente tenga prioridad por ser
posterior, debe ser rechazada y devuelta a su origen donde debe
restablecerse a su valor original informado al usuario de este hecho.

Otro problema en los casos de prioridad por fecha de modificación es que
el reloj de uno de las bases de datos no funcione correctamente. Si esta
base de datos esta instalada en un servidor conectado permanentemente a
internet se pueden poner utilidades para que se sincronice la hora de
forma periodica, pero si está en una pequeña instalación con uno o dos
equipos funcionando en windows no es tan fácil. Me he encontrado con
usuarios que simplemente le han hecho un doble click en el relojito de
windows para ver el calendario y sin darse cuenta (por lo menos eso
dicen) han adelantado el reloj 2 meses, hasta que el sistema se ha
vuelto a sincronizar ha estado grabando movimientos con esa fecha
incorrecta.

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