Replicacion de Base de datos Firebird
 

Estimados Amigos (as),
Necesito realizar una replicacion de dos bases de datos en dos vias, no tengo ni la mas minima idea de como hacerlo, si me colaboran con sus experiencias se lo agradecere.

Explícate mejor lo de las vías :)

Basicamente lo que necesito es replicar una base de datos en una sucursal y la base de datos de oficinas centrales. Osea, que se actualice en linea, si en la sucursal ingresan un dato, èste se actualice en la base de datos central y viceversa. He estado revisando el IBReplicator, pero sumamente tedioso ademas de que no me da confianza. Si me pueden sugerir otra forma de hacerlo lo agradecere.

Si no te quieres complicar mucho la vida, puedes utilizar el IB-Replicator de la misma IB-Phoenix (la empresa que está por detrás, apoyando Firebird).

http://www.ibphoenix.com/main.nfs?page=ibp_replicator

Esta es la opción más sencilla, después puedes optar por un replicador open-source como el FBReplicator

http://www.meta.com.au/index.php?opt...d=23&Itemid=30

Y finalmente puedes crearte tu propio Replicador (como hemos hecho muchos), por lo que si quieres hacerlo te podemos decir por donde empezar.

Saludos.

La replicación es una de las características en donde si MySQL tiene mejor soporte que FB (una de cal...). En MySQL se instala y configura con relativa facilidad dentro del mismo servidor sin utilizar programas adicionales, requiere poquísimos recursos y dá la posibilidad de hacer clusters. Lo único malo es que no permite replicación de dos vías, solo Maestro-Esclavo pero aún así es muy bueno.

AzidRain, entonces segun lo que me indicas la mejor opcion seria utilizar MS-SQL??

Con los enlaces que ha indicado guillotmarc he montado (por probar) una réplica de base de datos en menos de 5 minutos. Con software libre y gratis :)

Fíjate que AzidRain habla de MySQL y no de MS-SQL, además la replicación que él comenta es unidireccional y no bidireccional (como tu necesitas).

Naturalmente MS-SQL es una gran base de datos (por algo tiene detrás la enorme inversión que hace en ella Microsoft), pero Firebird tiene sus propias ventajas sobre MS-SQL (y no solamente el precio).

Si ya te ha parecido enrevesado preparar la replicación con IB-Replicator, va a sorprenderte todo el montaje que hay que hacer para montarlo en MS-SQL.

La verdad es que el tema de la Replicación es muy sencillo, como ha comentado Casimiro en 5 minutos lo puedes tener en marcha con FBReplicator (donde encima tienes todo el código fuente en Delphi para hacer cualquier adaptación que pueda ser necesaria).

Hay que tener varias cosas en cuenta cuando montas un sistema en replicación. La más importante es que tienes que evitar la duplicación de códigos en la clave primaria. Es decir que si en un sitio entras un cliente nuevo con el código 912, en el otro no puedes entrar otro cliente con el mismo código, puesto que cuando repliques los datos un cliente va a sobreescribirse sobre el otro.

Tienes dos enfoques para evitarlo. Uno es no utilizar para nada enteros como clave primaria, y pasar a utilizar UUID, que se generan al azar y tienen una probabilidad infinisimal de repetición. La otra solución es segmentar las claves primarias, por ejemplo con una ubicación empezando a generar códigos desde el 10000 (10001, 10002, 10003, ....) y la otro desde 20000 (20001, 20002, ...), etc. ...

No vaciles en preguntar cualquier duda.

Saludos.

Me he limitado a instalar el programita de la empresa 'meta', asignar las bases de datos y listo.
He visto que el servicio estaba funcionando y poco más.
Ha sido sólo por probar, ya que este sistema en windows no me sirve porque todas nuestras instalaciones van con servidores linux. Aunque he visto que el IBreplicator de ibphoenix sí tiene una versión para linux, no lo he probado.

De todas formas estos sistemas de replicación por internet no son muy viables, salvo que la línea tenga un gran ancho de banda y la base de datos tenga pocos movimientos.
Estos sistemas de réplicas están ideados para una red local, (corregidme si me equivoco), para el caso de que exista un problema con el servidor principal, así siempre hay una réplica en otro servidor y poder seguir trabajando. Aunque para eso existe el sistema "shadow" de firebird que es muy simple de implementar y nos sirve lo mismo.

Para lo que quiere rmora, tener dos bases distintas en central y sucursal y que se autoactualicen automáticamente ambas (se repliquen :)), se supone que por internet, ni con firebird, ni con ninguna... y supongo que menos con mssql, que es más "armatoste", (de nuevo, corregidme si me equivoco :)).

Creo que le interesa más montar un cliente de terminal como ultravnc (al estilo de terminal server) y conectar a la central, así todos están trabajando con la misma base de datos.

Y en la central, donde está la base de datos, tener sistemas de replicación como se desee, discos externos, otro servidor, etc.

Hola Casimiro.

No hace falta que ejecutes los Replicadores en el mismo Servidor, funcionarán igual de bien corriendo en una máquina Windows cualquiera de la red con acceso al Servidor Linux.

En muchos de mis clientes utilizamos la replicación para mantener sincronizadas sus bases de datos de distintas tiendas. No necesitas mucho ancho de banda puesto que la replicación no es síncrona, no se replica a medida que se van introduciendo los datos, sino que se hace de forma asíncrona, es decir, cada cierto tiempo (programable) se pasan todos los datos introducidos en ese intervalo.

Nuestro grupo más grande tiene 15 tiendas en replicación constante. Pero Xavi (cadetill) trabajó en el sistema de replicación en Firebird de una cadena farmacéutica con centenares de sucursales replicando (básicamente el sistema es el mismo).

Como la replicación no es síncrona (no es lo mismo que un shadow remoto), no hay problema, la replicación va haciendo a su ritmo que eso no ralentiza tu sistema.

Aunque la verdad es que nunca he utilizado una Replicación con conexión directa como hacen en el FBReplicator. Mi motor de replicación utiliza paquetes de datos intermedios. Cada x minutos miro los Logs de replicación (tablas mantenidas mediante triggers que informan de los cambios que se hacen en la base de datos) y empaqueto todos estos cambios en un archivo XML comprimido que subo a un Servidor FTP. De la misma forma, compruebo que en el Servidor FTP no haya paquetes que me hayan subido para esta tienda, en cuyo caso los descargo, los descomprimo y los ingreso en la base de datos.

Esto te permite seguir replicando incluso cuando no tienes conexiones permanentes a Internet (por ejemplo un comercial con un portatil). Cuando puede conectar a Internet, sube todos sus cambios y descarga todo lo que han subido las otras ubicaciones. Además utilizas mucho menos tráfico de Internet, puesto que preparas localmente todos los datos y los envías de golpe al Servidor FTP comprimidos, en cambio en el sistema del FBReplicator los datos se intercambian directamente desde un Replicador al Servidor Firebird remoto, mediante una larga serie de consultas, y todos sabemos que el protocolo de Firebird hace bastantes viajes de ida y vuelta para cada consulta a un servidor, por lo que es lento al correr sobre Internet (que tiene una gran latencia entre cada ida y vuelta).

Aunque la verdad es que esto es complicarse un poco la vida, y el sistema del FBReplicator también debería funcionar perfectamente.

Suelen poner Terminal Server en estos casos. Pero no me gusta, la verdad es que se nota el retraso de no estar trabajando en local, y además si se corta Internet por cualquier tontería no puedes trabajar (y si cortan Internet en la central, ya no trabaja nadie). En cambio en un sistema de replicación, la gente sigue trabajando (con datos sin actualizar) y cuando vuelva la conexión a Internet se pasarán todos los datos introducidos durante ese intervalo sin conexión.

Muy interesante lo que me cuentas, aunque, como siempre, cada caso es un mundo :).
El caso que cuentas de cadetill y supongo que el tuyo, son muy particulares, por ejemplo el de las farmacias sólo será sincronizar las medicinas que se venden y hacer pedidos de las que necesiten. Las farmacias no llevan (normalmente ) clientes, almacenes, bancos, etc. O sea, que seguramente la replicación es sólo de algunas tablas porque las otras no serán necesarias o tendrán un movimiento mínimo (supongo).
En mi caso es más complejo porque sería actualizar/replicar toda la base de datos... que ahora mismo tiene 263 tablas y además campos blob con imágenes y documentos muy variados. Algunos de nuestros clientes han pasado los 20 Gb y eso por internet... :S
En realidad lo hemos probado con un cluster Heartbeat por internet y era morirse de pena (en red local va bien), pero si pudiésemos limitarnos a sólamente los artículos, clientes y poco más... entonces sí sería una buena opción la replicación que comentas.
En nuestro caso ni los representantes pueden vender con precios "de ayer", necesitan tener el precio y el stok "ahora mismo", como si estuviesen en la central, así que también llevan conexión a la central y trabajan al igual que las sucursales, todos contra el servidor central.
De todas formas, está muy interesante el sistema de replicación que comentas para según que negocios.

Yo estoy trabajando precisamente en un sistema de replicacion propio como el de gillotmarc solo que de forma directa, evaluare la posibilidad de hacerlo con un ftp de por medio.

Hola Casimiro.

Es cierto que con un sistema de replicación nunca tienes datos garantizados, no sabes cuan buenos pueden ser. Por eso para montar el sistema que comentas habría que complementarlo con otro sistema.

Es decir, en un caso como el vuestro, yo quizás montaría igualmente el sistema de replicación, pero para los datos críticos, donde se necesite la información exacta en la central (como precios o stock), montaría un WebService, de forma que esos datos se consulten directamente a la central.

Pero el resto se puede replicar perfectamente.

Mi aplicación consta de 131 tablas, que se replican todas, y en el caso del cliente con 15 tiendas, en estos momentos tiene 900Mb de tamaño (no incluye imágenes, documentos, etc. ..., todo es pura información).

Aunque está lejos de los 20Gb., para el caso creo que es lo mismo. Puesto que como te puedes imaginar, tampoco pasamos nunca esos 900Mb por Internet, excepto cuando se corrompe la base de datos en una tienda, o bien cuando se monta una tienda nueva, pero en lugar de replicar todos los datos (lo cual sería lentísimo, puesto que haría INSERTS para todos los registros de la Base de Datos), simplemente les envío una copia de la base de datos del servidor central (previamente configurada para actuar como la tienda destino). Esta es otra ventaja del sistema de replicación, ya no necesitan copias de seguridad, puesto que cada tienda es en si misma una copia de seguridad de los datos del resto de tiendas.

Solo se pasan los datos introducidos o modificados desde la última replicación, el tamaño promedio del archivo de datos que se envía cada 10 minutos es de unos 20kb.

En casos donde una tienda ha estado un mes sin replicar debido a cambios en el ADSL o lo que sea, lo más grande que se suele pasar es un archivo del orden de 1Mb (aquí nos caben perfectamente, comprimidos en un zip, los miles de registros que se han introducido durante ese mes).

Claro que como dices, cada caso es un mundo, así que imagino que habrá casos donde el volumen de información que se introduce a diario puede hacer inviable la replicación, pero la verdad es que no creo que sean muchos (quizás en un sistema donde se almacenan muchos archivos binarios grandes, como imágenes, etc. ...).

Piensa que el clúster que montasteis era síncrono (los datos se pasan en tiempo real, ¿ no ?), por eso no tendría un buen rendimiento en Internet. Pero en un sistema de replicación, donde la actualización es asíncrona, no deberías tener esos problemas. El precio que pagas es que la información no está actualizada en tiempo real, pero eso en la inmensa mayoría de tablas no es ningún problema (en el tiempo que tardas llamando a la otra tienda para comentarles que le echen un vistazo al cliente que acabas de añadir, ya habrán pasado unos minutos, y ya lo tendrán disponible).

Saludos.

Si tienes dudas sobre los Logs que hay que crear, o cualquier otro problema, no dudes en consultar.

Haz alguna prueba, para ve si la conexión directa te puede manejar el volumen de actualizaciones que tiene que hacer la replicación, y si no lo ves claro, utiliza el sistema de FTP puesto que en este sistema lo preparas todo en local, de forma muy rápida, y después solo tienes que hacer una única conexión a Internet, donde subes de golpe ese archivo. Te puedo asegurar de que podrás replicar una gran cantidad de datos de esta forma.

No hay mucha diferencia entre hacerlo en conexión directa o por FTP. Simplemente todos los datos de los que hay que hacer un INSERT o UPDATE en el destino, yo los pongo en un ClientDataset, lo guardo en un archivo, y los comprimo todos juntos en un zip.

El Servidor destino solo tiene que descargarse el zip, descomprimirlo y cada archivo es un ClientDataset, lo cargo en Delphi en un ClientDataset y lo recorro en un bucle, haciendo los correspondientes INSERT/UPDATE.

Saludos.

Sí, los usuarios finales (clientes) se conectan de esa forma mediante un servidor web que conecta a la base de datos del servidor central.

Todo lo que comentas me ha hecho pensar en cosas habituales que tenemos que sufrir con los jefes o mandos superiores. De primera hora les sugerí que usáramos una base de datos aparte únicamente para las imágenes y documentos, ya que esto facilitaría mucho el trabajo con la base de datos principal que se vería libre de esa carga, pero "donde hay patrón no manda marinero", así que todo está en la misma base de datos, el resultado es que ahora es un problema en algunos casos, por ejemplo el de la replicación :)

De todas formas, por lo que comentas, en tu caso no es un sistema de replicación "real", es realmente un sistema de exportación/importación de datos, eso sí es algo que tenemos implementado, aunque no automáticamente, requiere que el usuario lo realice, escoja las tablas y/o registros a exportar, lo envíe por ftp, email, pendrive, cd, etc. y luego en la sucursal importan lo que viene en ese fichero.
También tenemos un sistema como el que comentas que sí se hace automáticamente mendiante ftp, sin intervención del usuario, pero únicamente lo usan los representantes, que además llevan una versión "reducida" del programa.

Aunque por los datos estadísticos que das, voy a sugerir para que al menos se pruebe un sistema de replicación de estos (fbreplicator o ibreplicator), aunque no sean en tiempo real, puede ser que funcione... bueno, funcionará siempre y cuando a la secretaria no se le ocurra escanear las tarjetas de visita a unos 100 megas cada una :D, que últimamente tiene esa costumbre :confused:.

Y si me hicieran caso... también extraería todos los datos de campos blob que no sean de texto y los metía en otra base de datos separada, no es lo mismo una sóla de 20 Gb que tener dos, una de "datos" de 8 Gb y otra de "binarios" de 12 Gb :)

Gracias por la ayuda.

Ya tengo hecho la parte de los logs. (triggers configurables por el usuario).
Ya tengo tambien el sistema directo, mi replicacion por el momento solamente funciona en 2 vias de las tiendas a la central (por la IP Publica).
Creo que voy a tener que optar por la opcion de FTP porque precisamente una tienda quedo sin internet por 2 meses y esa carga es demasiado para pasarla de forma directa.
Aun tengo que depurar la aplicacion porque me meti a hacerlo con threads y a veces pela cables (actua de forma extraña). consume demasiada memoria, etc.

Precisamente eso es lo que tengo pensado hacer, utilizar clientdataset, y expotarlos a XML, ya que son unicamnte 3 tablas.

Saludos

Duda...
 

Saludos a tod@s l@s foristas:

Hasta ahora, aun no he tenido la necesidad de implementar un sistema donde se requiera replicación... pero creo que en poco tiempo lo voy a tener que hacer. Dándole vueltas a este asunto me salta la siguiente duda: ¿que sucede si tambien quiero replicar mi metadatos?, por lo que entiendo de sus comentarios anteriores las implementaciones que hacen de replicación son solo de datos, ¿es correcta esta aseveración? ¿No se si algunas de las herramientas que mencionan (IB-Replicator, etc), ademas de replicar los datos también lo hacen en los metadatos?

Saludos

Gerardo Suárez Trejo

Que tal Gallosuarez, te comento yo tuve que realizar una aplicacioncita para mantener actualizada tambien la metadata es bien facil ya que contamos en firebird con el IBScript que te permite ejecutar DDL. en la base de datos. Es algo bien sencillo, basta con llevar una bitacora de los cambios a la metadata y ejecutarla en orden en los otros sitios.

hola

Quisiera saber si alguno de ustedes me puede ayudar

ya instale el fbreplicator
pero no se como asignar las bases de datos.

si me pudieran ayudar con un ejemplo estaria muy agradecida

lo que necesitas es conseguir la herramienta IBreplicator , en lapagina del IbPhoenix , tiens que descargar la version manager de windows y la version de linux

Replicacion
 

estuve leyendo todo esto... y me parece reloco.... por lo buenos que esta.... mi duda no se capaz que esta de mas.... que pasa con los generadores???? que se usan como pk. En las tablas que tienen relacion Master/detail que pasa. Yo en mis tablas tengo Triggers que se dispara en situacion de uso normal, para generar los mov de cta cte, stock eso sigue igual...?? me imagino que si pues si no no se usaria, pero no entiendo como la hace??

Luis Roldan
Mar del Plata
Argentina

pd : GuillotMar, gracias por tu buena onda

Hola Luis.

En ese documento, tienes en uno de los últimos capítulos la problemática de las claves primarias (Unique Keys & Generators).

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

Se pueden seguir utilizando perfectamente generadores para asignar las claves primarias (aunque otra gente prefiere usar UUID's como clave primaria, los cuales se pueden generar mediante UDF's, o incluso funciones internas agregadas a los últimos Firebird).

La solución que propone el documento es separar las claves en cada ubicación mediante bloques. Es decir, en un sitio se asignan PK's de 0 a 999.999, en otro sitio de 1.000.000 a 1.999.999, etc ...

Las relaciones maestro-detalle no representan ningún problema.

Respecto a los Triggers que ya tienes en tus tablas, tampoco son ningún problema, puesto que en cada tabla puedes tener tantos triggers como quieras (tienen un orden, y se ejecutan todos esos triggers, uno detrás de otro, en el orden en que estén definidos).

Saludos.

Como lo menciona Guillotmarc es precisamente como yo lo tengo integrado, correlativos por BD.

Tocando el tema estoy por empezar el proceso en el cual voy a involucrar a un tercer ente (ftp) para poder enlazar, ya les contare como me va. :)

Yo personalmente no lo hago correlativo por BBDD, yo prefiero añadir un sufijo según la BBDD.

Es decir, utilizo un generador normal y corriente, y a medida que me da números 1, 2, 3, 4, ... pues si estoy en la base de datos nº 1, le añado un 01 detrás, de forma que me quedan : 101, 201, 301, 401, en cambio en la segunda base de datos me va generando los códigos : 102, 202, 302, ... Así estoy seguro de que nunca va a haber conflictos de clave primaria.

Saludos.

Hola Guillotmarc,

Buscando un replicador para mssql o mysql di con el foro y me gusto tu idea del replicador hecho en base a triggers. Mencionas que puedes ayudar para programar uno similiar asi que me atrevo a pedirte si podrias darme mas detalles y puntos a tomar en cuenta para implementar un replicador asi . Yo programo en vfp pero teniendo la idea general del programa creo que puedo implementarla en este lenguaje o posiblemente ni sea necesario y pueda ejecutarse como programa independiente en delphi ya que solo accesara las bases de datos correspondientes. Mi caso es igual a los comentados , una base de datos central con un ciento de bases de datos locales que deben replicar sus datos a la central ya que esta se utilizara para replicar a un servidor para emision de reportes y consultas consolidadas de varias sucursales. Muchas gracias de antemano. Mi correo es : dsalap @ gmail.com . Saludos a todos.

Hola.

Este es el documento básico que creo que hemos utilizado todos para montar nuestros mecanismos de Replicación en Firebird.

http://www.ibphoenix.com/resources/d...how_to/doc_316
Traducción automática por Google

Deberías leerlo y después si quieres lo comentamos, puesto que personalmente hay cosas que prefiero hacer distinto.

Por cierto, hemos hablado mucho de este tema en otras ocasiones. Te recomiendo que leas esos comentarios (utiliza la opción Buscar que tienes arriba del Foro a la derecha).

Especialmente te recomiendo que leas este hilo :

http://www.clubdelphi.com/foros/showthread.php?t=69827

Saludos

muchas gracias Marc, voy a revisar el documento y el enlace que comentas y luego me pondre en contacto nuevamente.

Saludos desde Cancun

Daniel S.

tipos de datos-replicación
 

tu que desarrollaste el replicador, como hiciste para manejar los diferentes tipos de datos que tienen las claves primarias en una base de datos.
Qué propiedades del campo de firebird puedo utilizar desde delphi para saber si es tipo varchar o integer, y poder realizar las consultas correctamente.

En qué tablas quedan almacenados las columnas y tipos de datos en firebird?

Agradezco sus comentarios

Código SQL [-]
select A.RDB$FIELD_NAME AS CAMPO, RDB$FIELD_TYPE AS TIPO_DATO
from RDB$RELATION_FIELDS A inner join RDB$FIELDS B on (A.RDB$FIELD_SOURCE = B.RDB$FIELD_NAME)
where (A.RDB$RELATION_NAME = :tabla)
ORDER BY RDB$FIELD_POSITION

y para la llave primaria

Código SQL [-]
select S.rdb$field_name as CAMPO, (select RDB$FIELD_TYPE
                                  from RDB$RELATION_FIELDS A inner join RDB$FIELDS B on (A.RDB$FIELD_SOURCE = B.RDB$FIELD_NAME)
                                  where (A.RDB$RELATION_NAME = i.rdb$relation_name) and (a.rdb$field_name = s.rdb$field_name)) AS TIPO_DATO

from ((rdb$indices i INNER JOIN rdb$index_segments s ON (i.rdb$unique_flag=1 and i.rdb$relation_name=:tabla and s.rdb$index_name=i.rdb$index_name)) INNER JOIN rdb$relation_constraints A
      ON s.rdb$index_name=a.rdb$index_name and rdb$constraint_type = 'PRIMARY KEY')


ORDER BY RDB$FIELD_POSITION

gracias
 

compañero, muchas gracias por su ayuda!!

Buenas a Todos, alguno de uds me puede ayudar con el FBREPLICATOR?

Bienvenido a clubdelphi, por favor, lee nuestra guía de estilo, gracias :)