clustering, replication o cómo??
 

Hola..

llevo un par de días buscando una solución a un problema que tenemos y no se como resolverlo todavía.

vamos a desarrollar una aplicación de gestión para nuestra empresa que cuenta con varias delegaciones.

la idea es que todas tiren del mismo servidor ubicado de la central, lo que pasa es que no se cómo actuar cuando se den fallos de conexión..

pensaba que eso estaba solucionado con las herramientas de replicación de datos, para tener bases de datos locales y que estén todas replicadas, pero veo que es una tecnología no demasiado usable para mantener copias consistentes de las BBDD..

realmente estoy un poco frustrado porque no encuentro nada que me oriente y esto es más viejo que la mojama, osea que no me gustaría reinventar la rueda..

un saludete

Esimado Stator:

El objetivo de una base es unificar procesos, ya sea de distintas areas o delegaciones. La cuestion es que no redunde(repita) la informacion. Asi cada area puede compartir y procesar la misma informacion. A mi parecer, estas haciendo una tormenta en un vaso de agua. Solo tienes que definir los procesos especificos de cada area, luego ver como se interrelacion para luego definir la estructura de base. Asi tendras una base de datos q cumpla con su objetivo.

Si aun te quedan dudas solo escribe a este foro

Esperando q te haya servido esto, me despido.

Saludos.

¿y no te interesa estar conectado online con la central?, es cuestión de planificar los datos que van a "viajar" y llevar un buen control

hola a todos y gracias por las respuestas..

la idea es la siguiente..

hay una central y n delegaciones.

todos pueden y deben hacer las mismas operaciones.. imaginaros, las típicas de dar de alta clientes, facturación, etc...

en principio, todos van a estar conectados al servidor firebird de la central. (la central y las delegaciones tirando de la misma BD)...

hasta ahí todo correcto y perfecto..

el problema es ir un paso más allá y plantearnos el supuesto de que la conexión o el servidor principal se caigan.. qué hacemos?

la solución que se me ocurrió es tener una réplica en cada una de las delegaciones de la bd principal para así no depender de las conexiones a inet.. el problema es que esta solución, o yo no se como enfocarla, o no he dado con las herramientas adecuadas, o todavía está en pañales..

mi entorno ideal sería tener un "grupo" de servidores geográficamente dispersos que actuasen como si fuese UNO solo... me refiero a protocolo de bloqueos de registros, etc...

el caso es que no he encontrado como hacerlo en firebird y también desconozco si con otro SGBD se puede hacer...

alguién más quiere aportar sus 2 cents?

thanks..

El problema es ese, que 2 céntimos es poco para hacer algo en "condiciones" que garantizase la continuidad del trabajo en caso de "cortes". Habría que estudiar a fondo el asunto para buscar soluciones... que costarían un poco más de esos 2 cénts.

;)nos ha jodido mayo!!!;)

gracias Casimiro Notevi por tu respuesta.. me has clarificado mucho mis dudas.:D

un saludete

Es que los milagros no existen. Es como cuando un cliente me dice:
cliente: qué puedo hacer para seguir trabajando si se va la luz?
yo: poner un SAI (UPS)
cliente: ¿y si se queda sin batería y aun no ha vuelto la luz?
yo: poner un generador de electricidad
cliente: pero eso cuesta mucho dinero
yo: pues te esperas a que venga la luz... no existen los milagros.

En tu caso es parecido, para evitar problemas de "caídas" del servidor, la única solución es tener otro servidor con la base de datos actualizada, esto no es problema, salvo el económico, se puede mantener una "shadow" o "réplica" en tiempo real y si se cae el servidor, lo único que hay que hacer es cambiar la IP al "secundario" y ya está trabajando de nuevo todo el mundo.
Pero si se corta la conexión de internet... en ese caso se puede tener otra conexión de internet, se redirige el servidor al otro router y listo.
Pero si no hay línea telefónica alguna... ¿entonces qué?, se debe mantener una copia de la base de datos de la central en cada una de las sucursales, dependiendo de la lejanía, se puede copiar a "mano", por internet, en CD, etc... Pero si no es posible mantener la copia actualizada de la central en cada una de las sucursales... pues entonces no hay nada que hacer. Apuntar en papel los cambios y luego actualizarlos cuando funcione la red, internet, el servidor o lo que estuviese averiado.

Si la base de datos de la central no es muy grande y se hace factible el copiarla en cada sucursal, pues entonces se puede habilitar alguna posibilidad de crear ficheros "log" con los movimientos que se realicen, y en caso de "cortes o caidas", restaurar los datos desde ese fichero log.

En fin, que todo es muy relativo y depende mucho de cada uno, en tu caso habría que saber cuántas sucursales, qué tipo de conexión, qué hardware tenéis, qué sistema operativo, qué prioridades, con qué presupuesto se cuenta, cuál es el tamaño de la base de datos, etc...

Por ejemplo, en caso de uno de mis clientes con una base de datos que mide al día de hoy: 3.866.357 Kb (casi 4 Gigabytes) no sería factible copiarla por la red, ni por internet, ni en cds... así que habría que eliminar muchas posibilidades, pero si es la base de datos de otro cliente que mide menos, alomejor es factible, habría que estudiarlo.

En fin, que no hay nada nuevo que facilite hacer lo que quieres, existe lo de siempre. Así que hay que estudiarlo en profundidad y decidir según lo que interese más.

Tienes varias alternativas. Ninguna facil.

1- Creas un "cache" local de los datos. Puedes usar una firebird embeida.

La idea es que para tablas como listas de ciudades y esas cosas haces un select al servidor y lo ingresas a la BD local. Luego sigues usando la local, a menos que se actualize la remota.

Si la remota se actualiza, re-descarga los datos.

Si estas offline, creas los datos SIN ID (o pones un ID negativo) y tienes que hacer una operacion de reconciliacion.

Lo horrible empieza con tablas de movimiento. Esto nos lleva a:

2- Utilizas un sistema de mensajeria

Los sistemas de mensajeria son los que estan diseñados para este tipo de operaciones, pero exigue depender de un sistema como el de MS o del de IBM u otro. Las operaciones son en batch... este tema es un poquin complejo...

3- Usas la funcionalidad de tu base de datos

Que en este caso, debes buscar una solucion de terceros para hacer replicacion.

Por donde lo veas, es complicado. Te recomiendo eso si de una buena vez usa una columna timestamp en todas las tablas donde se necesite, ya que simplifica mucho estos esquemas.

Tambien, seria bueno que miraras DataAbstract de RemObjects (www.remobjects.com) que tienen una solucion (igual ASTA y otros)

Con RemObjects se soporta clustering, failover (a nivel de comunicaciones) y esta bien la parte de manejor offline de datos...