Diantre. Estas metiendote en algo que va ser facil o super difícil. Hacer BD distribuidas, es jodido. Hacerlas donde hay multiples escrituras y deben todas sincronizarse a un modelo estable y solido al final, es super super jodido.
De entrada: Lo mejor es simplemente que el cliente compre un mejor internet. Y que la BD este en un hosting aparte. No es una recomendación aleatoria pa ponerla en la lista de lindas ideas. Es la mejor opción, considerando la experiencia de muchos en este campo.
Pero porque hacerlo facil si se puede difícil? Pa eso programamos!!!!
P.D: Estoy en este momento pensando como resolver este mismo tema. Llevo *meses* investigando y mirando a ver si existe una solución *facil*. Pobre de mi.
----
El problema fundamental y mayor lio esta en la parte: "y la conexion se cae, luego se sincroniza" Repasa la
paradoja de los 2 generales (Spoiler: Esta demostrado es imposible de resolver satisfactoriamente). Contrasta conque empresas como
Apple han intentado resolver el punto, y les va mal. Existen algunas alternativas, como
CouchDB -que no es para nada un motor sql- que pueden funcionar.
Osea, si hay operaciones asincronicas y poco fiables, se puede tornar el asunto muy serio. Y lo peor? Si no tienes mucha experiencia podrias no darte cuenta de lo serio hasta que empices a recibir llamadas constantes con quejas de informacion perdida, corrompida u obsoleta.
Enemigo #1: Datos asincronicos
El segundo problema es que hay mas de "una fuente de la verdad". Cuando hay un sistema "maestro:escritura-replica:solo lectura" es relativamente facil de resolver (es por eso que puedes hacer
un cluster de BDs). En este modelo, el maestro es la definitiva "fuente de la verdad". Si un cliente esta corrompido, puedes reconstruir y compararlo contra el master, y la perdida de datos es local a solo ese cliente.
Aqui la *patada* es que tu maestro es un general ebrio, y propenso a perderse del radar! Por lo tanto, si el maestro esta fuera de combate, la informacion estara diseminada entre los clientes. Algunos clientes estaran mas adelante que otros, teniendo datos mas ciertos. Si te imaginas lo que implica un general en una batalla, ebrio, dormido, y poco fiable, pues eso es lo que describes.
Enemigo #2: Necesitas que sea un maestro-esclavos y dices que tu maestro es un inutil bueno para nada, a veces.
El tercero y mas comun es si los datos se actualizan simultanea y/o retroactivamente entre los clientes. Osea, 2 clientes pueden modificar el mismo registro, cuando les de la gana. Eso se resuelve facil en un sistema 2 niveles (con bloqueos o actualizaciones optimistas con resolucion de conflictos) pero estas metido con los otros 2.
Si *cada cliente* es dueño de sus propios datos en *independencia* de los demas o si los datos son "append/forward" entonces es *facil* incluso con los 3 lios juntos. Osea, es facil sincronizar solo inserciones. Sincronizar actualizaciones, y borrados, es lo que friega el asunto a niveles epicos.
Enemigo #3: Actualizaciones en conflicto-concurrentes (y dispares en el tiempo, pa rematar de ponerlo bonito).
---------
Reiterando la recomendacion anterior: La arquitectura externa de un sistema es *parte* integral de la eficacia del mismo. Una buena red, un buen configurado servidor, un motor de datos bien tenido, todo eso hace que el sistema opere *bien*. Cuando la infraestructura es correcta, los programas fluyen. Pero es cuando hay que darle vueltas para parchear (hackear) alrededor de las fallas de las infraestructuras que las cosa se ponen feas.
Sincronizar datos es posible. Pero no veo un escenario donde el maestro sea poco fiable y esperar que las cosas salgan bien. Si *definitivamente* es tan dificil pa tu cliente adquirir un mejor internet, la segunda mejor opcion es mover la BD central (el master) a un servidor en internet.
Luego, puedes aplicar varios modelos para sincronizar la informacion, pero es necesario saber un poco mas que tan "freago" es tu caso (ej: como son los datos, si se puede o no particionar por cliente, si hay lios de relaciones, mas bien, un esquema general de como es la BD).
Considera, que este camino es mas esforzado en programacion y testeo. Como te conte, llevo meses evaluando que hacer, porque francamente, preferiria no cojer ese camino (en mi caso, es necesario, si quiero, como deseo, que
BestSeller pueda ser usado por cientos de personas con o sin conexion de internet... aunque por otro lado, podria desechar la idea de que funcione sin internet, y !bingo! problema resuelto).