Sugerencias para replicacion en sucursales

[IVAND]

Hola a todos

Se q es un tema q se ha hablado aqui varias veces , pero cuando se pasa 16 horas en un computador pensando como hacer ya uno como q no da mas

Si pudieran orientarme un poco mas sobre este tema o alguien me puede guiar se lo agradeceria (se q Guillotmarc tiene un buen replicador espero me pueda el y todos ustedes dar la mano es las siguientes dudas )


Necesito saber si me puedes ayudar con el tema de replicacion estoy utilizando fb1.5 y delphi 6 , he visto algunas respuestas tuyas con este tema y tengo algunas

Si hubiese un replicador q haga lo q yo necesito estaria dispuesto a comprar las licencias

Los detalles q quisiera saber son los siguientes

1.- EL sistema sera instalado en varias sucursales ... estas estaran en linea siempre pero uno nunca sabe q puede salir mal (ahi es donde entra la opcion de saber q se ha enviado y q no)

2.- Una sucursal puede o podria estar sin coneccion maximo unas dos o 3 horas razon suficiente para generar unos 1000 registros (factura , detalle de facturas , forma de pagos , historicos, saldos acumulados , clientes etc)

3.- Los datos o la estructura de la base maestra como debe de ser

en fin muchas dudas, si fueras tan amable queria saber tu opinion y disponibilidad para ayudarme en este tema muy importante y guiarme un poco

De antemano muchas gracias por tu tiempo

[Casimiro Notevi]

Hola, IVAND, si quieres puedes enviarle un mensaje privado a Guillotmarc enlazándole este tema, así estarás seguro de que no se le pasará esta pregunta tuya.

[guillotmarc]

Hola Iván.

Creo que todos los que hemos programados nuestros propios motores de replicación nos hemos basado en este documento, es todo un clásico (y muy bien explicado). Léelo y no vaciles en consultar cualquier duda.

http://www.ibphoenix.com/main.nfs?a=...ge=ibp_howto10

El motor de Firebird ha evolucionado bastante en estos años, así que algunas cosas se pueden simplificar. El principal cambio que te recomiendo es utilizar un Rol en lugar del nombre de Usuario, para detectar cuando se está modificando una tabla desde dentro del motor de replicación.

Es decir en los Triggers que se hacen para los sistemas bidireccionales, sustituímos la linea :

IF (USER <> "REPLICATE") THEN

por la línea :

IF (CURRENT_ROLE <> "REPLICATE") THEN

La ventaja de usar un Rol en lugar de un Usuario, es que deberías asignar derechos sobre todas las tablas para el nuevo usuario REPLICACION, cosa que es laboriosa y es fácil olvidarte en el futuro a medida que añades tablas al sistema. En cambio no es necesario añadir derechos a las tablas en los roles (puesto que el usuario que vienes utilizando ya tiene acceso a esas tablas).

Saludos.

[IVAND]

Gracias a los dos por sus respuestas , leere el tema y no olvidare preguntarles


Muchas gracias

Espero no ser muy molestoso y si consideran q pueden venderme alguna licencia de su replicador no duden en decirlo

[IVAND]

Ya he echo una prueba y me ha salido super bien ... hay un par de cositas q me gustaria q me orientaran , una vez q seguire probando les molestare gracias nuevamente

Tendre q cambiar un par de cositas en la base de datos como claves unicas

[guillotmarc]

Hola Iván, me alegra que vayas avanzando bien.

Respecto a las claves únicas. Tienes varias opciones.

1) Utilizar un UUID como clave primaria en todas las tablas (Es una solución sencilla, en la que no te tienes que preocupar de más problemas. Yo no la utilizo porqué es incómoda a la hora de trabajar con los datos, si quieres lanzar una consulta para ver todas las líneas de una factura, tendrás que escribir una consulta con una clave secundaria de 16 dígitos).

http://www.firebirdfaq.org/faq98/

NOTA: Estos UUID se guardan en campos varchar(16) con el charset OCTETS.

2) Seguir utilizando un Entero largo, pero en este caso te tienes que asegurar de que no pueden entrar en conflicto los números asignados en las distintas ubicaciones en Replicación.

Para solventar el punto 2) algunos amigos lo han solventado reservando paquetes. Es decir, el primer servidor asignará claves primarias del 1 al 10.000, el segundo servidor del 10.001 al 20.000, etc. ...

A mi me parece muy laborioso, y además tienes que tener en cuenta de que un servidor puede agotar todas las claves primarias que tenía asignadas, y se le ha de asignar un nuevo paquete.

Personalmente he optado por añadir un sufijo a las claves primarias. Es decir todos los claves primarias creadas por el primer servidor acaban en 01, las creadas por el segundo acaban en 02, etc. ...

Para ello tengo una tabla CONFIG, donde se guarda el campo UBICACION (que indica si es el servidor 1, 2, 3, 4, ...).

Asi pués, en el momento de asignar una nueva clave primaria, la calculo de la forma habitual, con un generador, pero mediante una consulta de este estilo :

select gen_id(GENERADOR_TABLA, 1) * 100 + UBICACION
from CONFIG

[IVAND]

Excelente respuesta

Ya he probado con la replicacion en una via y ademas controlando la coneccion a con la sucursal para evitar q el dato se pierda ... segun el ejemplo q esta en la pagina q me indicas

Segun tu experiencia no es muy pesado este metodo de hacer consultas e ir insertando los datos o es mejor trabajar como dices creando archivos planos o xml y subirlos a un servidor Ftp

Espero sugerencias .... este es un proyecto q debo de entregarlo en unas dos semanas mas o menos , es el tiempo q abriran una nueva sucursal y probaremos este sistema

Nota : Aunque me parece q como solo barre una tabla y de ahi lanza consultas pequenas no deberia tener ningun problema pero pues es mejor preguntar a ver si los tiros van por otra parte y mas eficientemente

[guillotmarc]

Sinceramente no lo sé.

Yo utilizo el sistema de empaquetar los datos a replicar en un archivo y subirlos por FTP por comodidad, ya que no tengo que andar abriendo puertos en los routers de los servidores en replicación (muchos están en ordenadores de clientes y no tengo acceso a ello ni las contraseñas necesarias). Además no me tengo que preocupar que los servidores en replicación estén activos en un momento determinado, y con conexión a Internet, yo subo los datos por FTP y él ya los leerá cuando pueda.

Pero la verdad es que te complica la programación, no es lo mismo un motor de replicación con todos los servidores en línea, que andar intercambiando paquetes por FTP.

Si te sirve el método de replicar cuando los servidores están en línea (y si te encuentras con que el servidor destino no está en línea, entonces no se replica nada y toda la información queda pendiente para una conexión posterior), yo no me complicaría mucho la vida creando los paquetes por FTP.

Lo que no te puedo decir es el volumen de información que puede tratar un motor de replicación on-line por Internet, puesto que todos sabemos que el protocolo de comunicación de Firebird es poco eficiente, hace muchos viajes de ida y vuelta, y por lo tanto las consultas por Internet son bastante lentas.

Pero en principio no debería ser muy importante, ya que la información tardará más o menos en pasarse, pero siempre se acabará pasando (a menos que el volumen sea tan grande que ni siquiera aprovechando los tiempos en que no se añade nueva información, el motor de replicación no tiene tiempo de ponerse al día).

Lo mejor es probarlo, a ver que tal se comporta y que volumen de información puede absorver (yo no he hecho esta prueba por Internet, ya que desde el principio decidí trabajar desconectado, medianto archivos subidos por FTP). Simplemente recuerda de utilizar la última versión disponible de Servidor de Firebird y de librería cliente (fbclient.dll), puesto que en cada nueva versión de Firebird suelen mejorar bastante el protocolo de comunicación y reducen los viajes de ida y vuelta (que en Internet, dada la gran latencia, son lo que más te perjudica, y no tanto el volumen de información intercambiada) necesarios para lanzar cada consulta.

[guillotmarc]

Mecachis en la mar. ¿ Es normal no poder modificar tus propios mensajes ?.

He querido añadir información respecto a como se haría para intercambiar la información mediante paquetes de datos en archivos que se suben por FTP, y el sistema no me lo ha aceptado porqué he tardado más de 20 minutos en escribirlo, perdiendo todo el texto entrado.

No me apetece volver a escribirlo sin saber siquiera si piensas utilizarlo. Pero si te animas a trabajar con los servidores desconectados, dilo y te explico como lo hago yo.

[Casimiro Notevi]

Empezado por guillotmarc

Mecachis en la mar. ¿ Es normal no poder modificar tus propios mensajes ?.

Creo que hay un límite de 30 minutos, se puso porque había gente que se dedicaba a modificar y, sobre todo, a borrar mensajes anteriores dejando totalmente inservibles los hilos.

Antes de abandonar tenías que haber copiado el texto y abrir un nuevo post.


p.d. Casi siempre pagan justos por pecadores, cierto, pero muchas veces no queda más remedio que actuar así. Voy a comentar con los moderadores por si acaso hay alguna opción que permita modificar mensajes a los usuarios que tengan más de un número determinado de mensajes.

[guillotmarc]

Empezado por Casimiro Notevi

Antes de abandonar tenías que haber copiado el texto y abrir un nuevo post.

No he podido, cuando sale el aviso de que no se puede modificar el post ya no tienes el texto que querías añadir, y al volver para atrás tampoco recuperas el texto que habías modificado.

Gracias por la aclaración.

Saludos.

[Casimiro Notevi]

vaya, sí que da rabia una situación así.
Cuando la respuesta es "larga" yo tengo costumbre de escribirla en un editor, la reviso, corrijo faltas, etc. y luego la copia a clubdelphi.
Es que también me ha pasado varias veces lo que comentas, más que nada dándole a "vista previa" y luego no me acuerdo de "enviar respuesta" y se pierde todo lo escrito.

[IVAND]

Si no es mucha molestia seria importante tratar con los dos temas a la vez , es decir trabajar en linea y desconectado a ver cual metodo es mejor y en q momento decidirse


Si fueras tan amable en explicarmelo te lo agradeceria un mundo

Nota: voy a empezar a revisar la pasada de datos en dos vias es decir una sucursal envia informacion a la principal y la principal le envia informacion a la agencia

Ahi es donde comentas q se debe tener otro usuario en la base de datos ?


Gracias por la respuesta

[IVAND]

Me olvidaba indicarles que la informacion enviada de las sucursales seran solamente de las tablas cab_fac , det_fac , form_pago , his_mov,cab_diario ,det_diario y una tabla q utilizo para actualizar el inventario en cada sucursal

y la q envia la matriz a las sucursales seran solamente de clientes , y productos creados nuevos , las sucursales no podran crear productos ni bodegas solamente vender y cobrar

[rastafarey]

Lso que puedan leer el codigo del replicador que viene en ib_objects veran que es una de las soluciones mas praticas que he visto. Solo que hay que agregarles uans cositas entras a la base de datos.

[IVAND]

Hola a todos

Guillotmarc si no es mucha molestia me podrias indicar como haces para trabajar con los servidores desconectados ya he logrado hacer funcionar la replicacion en una via y en dos vias aun estoy intentado pero seguro sera solo cosa de revisar


Gracias por tu amable explicacion

[guillotmarc]

Hola Iván.

En el fondo es muy sencillo. No hay que hacer mucho más que en una replicación con servidores conectados.

Tienes tu tabla de LOGS donde se especifican todos los registros que hay que traspasar. Pues abres en un ClientDataset el contenido de la tabla LOGS y lo guardas en un archivo (por ejemplo en un archivo XML, ya que el ClientDataset te da distintas opciones para guardar).

Naturalmente con solo esa información, otro servidor no va a poder replicar los datos. Ahora te queda recorrer todas las tablas a replicar, y para cada una de ellas cargar en un ClientDataset los registros que se replicaran. Ejplo.:

select * from TABLA1
where ID in (select REGISTRO_ID from LOGS where TABLA_ID = n)

Cada uno de estos ClientDatasets lo tienes que guardar también en un archivo XML.

Una vez has pasado a archivos XML la tabla de LOGS, y los datos a replicar de todas las tablas en replicación, entonces puedes empaquetar todos estos archivos XML en un archivo ZIP.

Finalmente, cuando tienes todos los datos necesarios para una replicación, en ese archivo ZIP, lo subes a una carpeta FTP, para que esté disponible on-line. De manera que el segundo servidor, cuando se conecte a Internet, o cada cierto tiempo (yo lo suelo programar para que busque nuevos paquetes cada 5 minutos), solo le queda conectarse a esa carpeta FTP y descargar todos los archivos ZIP de replicación que allí se encuentren.

El proceso contrario. La importación de estos datos, tampoco tiene nada del otro mundo.

Solo tienes que descomprimir un archivo ZIP con los datos de una replicación. Cada archivo XML contiene los datos para ser cargados en un ClientDataset (uno para la tabla de LOGS y el resto para cada una de las tablas que se replican).

Así que una vez cargada esa información en los correspondientes ClientDatasets, ya solo resta hacer exactamente lo mismo que hariamos si estuvieramos replicando con los servidores conectados.

Es decir recorremos la tabla de LOGS (el ClientDataset donde la tenemos cargada) y para cada registro hacemos el correspondiente INSERT, UPDATE o DELETE en el servidor de destino. Para los INSERT o UPDATEs, la información a insertar la sacamos del ClientDataset correspondiente a esa tabla (ya que no lo podemos consultar directamente en el Servidor de Origen).

Finalmente ya solo te queda establecer un sistema de numeración de las paquetes a replicar, para asegurarte de que no se te quedan olvidados (por ejplo. por un error en el servidor FTP) paquetes sin importar.

Cualquier cosa que no veas clara, consultalo y lo comentamos.

Saludos.

[IVAND]

Gracias, como siempre muy explicado probare y te molestare por cualquier cosa


De nuevo muchas gracias

[guillotmarc]

El documento clásico de replicación en Interbase (y por tanto en Firebird), que citaba en el post #3, ha cambiado de ubicación.

Ahora lo podéis encontrar en : http://www.ibphoenix.com/resources/d...how_to/doc_316

Saludos.

[Casimiro Notevi]

Gracias por avisar