replica con mysql

[Rodrigo Gutierrez Torres]

Me da la sensación que es como el caso de una casa matriz que centraliza
toda la información; y sucursales, que sólo tienen la parte de la base
de datos que les interesa.
De ser así, sigue leyendo; sino, déjalo hasta aquí... Veo que sigues
leyendo... pues bien, creo que la alternativa más viable es usar un
"Merge", que entiendo no está implementado para MySQL, por lo que
tendrás que hacerlo "a mano", pero no es difícil. Espero no complicarme
en la explicación, por lo que sólo voy a pensar en una tabla: la de
clientes.

1. En un primer instante, sólo la base de datos central tiene la
información completa. Mediante algún procedimiento discriminatorio, como
por ejemplo la región a la que pertenece el cliente, decido enviar sólo
esa parte a cada sucursal regional. Sabemos que los clientes tienen una
llave principal que es el RUT, pero necesitaremos un segundo campo para
saber qué hacer, que llamaremos STATUS (a los que desarrollan para PALM
ya se les alumbró el resto del proceso :) que podrá tener cuatro
estados: 0: nada, 2: eliminar, 4: modificado, 8: nuevo.

2. Bloqueo la Base de Datos para sólo lectura, distribuyo la tabla a las
distintas sucursales y establezco en la BD central y regionales el
STATUS para todos los registros en 0. (OJO: Es importante tener definido
el problema de los permisos sobre los registros de la tabla. Cuando
implementes te darás cuenta por qué;)

3. Si se actualiza el registro de un cliente en alguna de las BDs, el
STATUS se debe establecer en 4. Si se decide eliminarlo el STATUS se
establece en 2 (pero no se borra de ninguna de las BD). Cuando se
ingresa un nuevo registro, este ingresa con STATUS 8.

La parte más difícil es la sincronización:

4. Sólo se transmiten los registros modificados y la única BD totalmente
confiable es la central (aunque no sea cierto!!!).

5. Se debe definir si la sincronización será de tipo PUSH (la BD central
_decide_ cuando sincronizar y empieza enviando ella las actualizaciones)
o PULL (las BDs regionales _deciden_ cuando sincronizar y son ellas las 
que envían las actualizaciones). Nunca he visto una mezcla ni he
intentado una... tengo la impresión que no funkan. Vamos a seguir
pensando que se trata de una sincronización PULL. Al final explico por
qué.

6. La BD regional manda sus registros con STATUS no 0. 
Los registros nuevos, los ingresa a la BD y los pone en STATUS 0. 
Para los eliminados, pone el STATUS en 2 _pero_no_elimina_. 
Para los modificados, compara las modificaciones con el registro que
ella tiene. Si no hay conflicto (sólo se modificó en la BD regional)
realiza el cambio y pone el STATUS en 0. En caso de haber conflicto, lo
normal es cortar por lo sano e ignorar la modificación hecha en la BD
regional (o la central si confías más en ella), pero también existe la
posibilidad de mezclar los registros mediante alguna regla de prioridad
y dejar el registro en la BD Central con STATUS 4.

7. La BD Central manda sus registros con STATUS no 0 a la regional. El
proceso es igual que el anterior, sólo que no existe para la
actualización mezcla, sino sólo reemplazo; y las eliminaciones se
aplican directamente.

8. Hay un flag que controla todo el proceso: cuando NO se está
produciendo sincronización, cuando se está produciendo en la Central,
cuando se está produciendo en la regional, cuando termina el proceso.
Este flag es importante porque cuando termina la sincronización en la BD
regional se envía un aviso, o cuando se ha pasado un tiempo límite de
espera en que llegue; la BD central elimina los registros marcados para
eliminación y actualiza los registros en STATUS 4 a 0 y marca el flag
como terminado. Además se debloquean las BDs para permitir lectura y
escritura.

9. En caso que el flag de la base de datos regional pase el tiempo
límite sin que le llegue la actualización del la BD Central, se supondrá
inconsistencia y solicitará una copia nueva de la parte de la base de
datos que le corresponde. Es por eso, que normalmente se programa un
ALIVE de la BD Central a la regional cuando se acerca el tiempo límite y
reiniciar la espera.

El proceso PULL, como observarás, sólo funciona si los clientes son
excluyentes entre regiones (un mismo cliente no está en dos regiones
simultaneamente). En caso de no ser así, se prefiere el método PUSH con
las consideraciones extras del caso que las dejo de "tarea para la
casa".

Espero no haber cometido errores en la explicación, haber sido
suficientemente claro y, por sobre todo, que te sirva :D

Salu2,

El mar, 08-02-2005 a las 18:19, Patolin . escribió:
> hola me voy a explicar mejor, si hay claves únicas, y hay otras tablas que 
> solo son de referncia para hacer mas facil el asunto para el usuario en la 
> interfaz gráfica, tengo una estructura de base de datos en la maquina X y 
> esa mims estructura en la maquina Y, la idea es que en ambas bases de datos 
> se mantenga la misma información, osea si yo ingreso datos en la maquina X, 
> estos deben ser replicados en la maquina Y, y viceversa, pero esas claves de 
> esos elementos no se repiten ya que son totalmente unicas para los usuarios 
> de las bases de datos tanto en la maquina X como en la Y, espero haberme 
> explicado mejor :D, ahora estas 2 bases de datos por l9o que he estado 
> leyendo se les llama master a master, ambas deben leer y escribir en la 
> otra, mas qeu anda escribir en la otra pero segun la definicion es así.
> 
> Gracias de ante mano.
> 
> --
> Atte
> Patricio Villalobos R.
> La Serena, Chile.
> 
> >No entendí mucho pero parece que tienes 2 bases ya en producción. Si
> >tienes llaves únicas (probablemente las tienes?) estas en problemas.
> >Vas a tener que homologar mabas bases antes de inicar la replicación.
> >Es importante tb que tengas claro que por esto mismo de las llaves vas
> >a poder escribir solo en una de las bases y vas a poder leer de las
> >dos. En caso contrario la replicación va a fallar por conflictos de
> >ID.
>