Re: Replicacion

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