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