|
|
 |
 |
|
Paypal | |
|
FTP | |
|
CCD | |
|
Buscar | |
|
Trucos | |
|
Trabajo | |
|
Foros | |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
 |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
10-07-2006
|
|||
|
|||
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.. 
|
|
#2
10-07-2006
|
||||
|
||||
|
Cita:
__________________
 La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal
|
|
#4
10-07-2006
|
||||
|
||||
|
Cita:
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.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal
|
|
#5
10-07-2006
|
||||
|
||||
|
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...
__________________
El malabarista.
|
|
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
 |
|
nos ha jodido mayo!!!
Modo Híbrido
