|
De entrada creo que el diseño de todo esta incorrecto. Solo debes tener un servidor y una BD para dar servicio tanto a los puntos de venta como a la aplicación administrativa. De esta forma la información está siempre actualizada y visible por todos los equipos.
Como lo planteas no te da opción de nada porque si necesitaras por ejemplo otra terminal POS, tendrías que instalar sus propias bases de datos.
Por lo menos así te lo entendí, pero suponiendo que la base de datos "local" de cada POS solo sea como respaldo en caso de cortes la cosa cambia:
1.- MySQL solo incluye de momento replicación líneal, es decir, en un solo sentido: 1 servidor maestro y "n" servidores esclavos. Si modificas un esclavo el servidor no toma el cuenta el cambio, además de que se crea un desmother con los datos.
2.- Para casos de POS que requieren poder seguir por su cuenta en caso de caerse el servidor, te comento como funciona el esquema usado por IBM en sus POS, los cuales puedes ver funcionando en muchos de los grandes supermercados, te puede servir para un nuevo diseño:
[quote]
Tenemos 2 servidores principales: 1 maestro, que llamaremos CC y un esclavo que llamaremos DD. Cada terminal punto de venta arranca, se conecta y se registra con el servidor CC y empieza a trabajar. La terminal no tiene copia de base de datos ni nada, todo depende del servidor. Si CC deja de funcionar, DD toma el control y sigue trabajando la cosa. Esto último no puede hacerse con MySQL así que vamos a brincarnos esto y suponer que tampoco DD está disponible.
En este momento la terminal no tiene acceso al catálogo de artículos y por lo tanto a los precios. El enfoque de IBM es indicar esto en l display y permitir el registro de artículos sólo mediante la combinación "precio a departamento". Es decir, se debe indicar el precio del artículo y el departamento al que se dirige la venta. La transacción se guarda localmente en la terminal indicando además los UPCs de los artículos.
Al regresar el servidor, las terminales le envían sus transacciones almacenadas, ésto solo para efectos de que el servidor disminuya el inventario de los UPCs escaneados y que sume las ventas en $ a los departamentos indicados. En el reporte de cierre del negocio apareceran los importes que fueron cobrados "sin sistema".
Aquí lo importante es que en el caso de IBM es casi imposible que se llegue a ese extremo, pues hay UPS además de la redundancia de los servidores.
[quote]
Otro supuesto, tienes un servidor ubicado en otro local o ciudad, aunque de todas formas puedes montar el servidor via remota, puedes optar por montar un servidor intermedio que sí esté fisicamente en el mismo lugar que los POS y hacer una aplicación que se encargue de ir actualizando al servidor principal.
|