La captura con la respuesta de Tom es que no se está ejecutando ningún tipo de agrupación, se le acaba escribiendo a dos servidores. Esto es un problema si desea garantizar la coherencia entre ellos. Considere lo que sucede cuando su cliente falla una escritura en el servidor remoto. ¿Deshace la escritura a local? ¿Qué le sucede a la aplicación cuando no puede escribir en el servidor remoto? ¿Qué sucede cuando no puedes leer del local?
El segundo problema es la física fundamental que plantea Joshua. Para un viaje de ida y vuelta, se habla de un mínimo teórico de 38 ms que deja un tiempo máximo de procesamiento teórico en ambos extremos (de tres sistemas) de 12 ms. Diría que la expectativa es demasiado y el ancho de banda no tiene nada que ver con la latencia en este caso. Podrías tener un tubo de 10GB y esos tiempos aún existen. Dicho eso, transferir 5k a través del continente en 12ms también es pedir mucho. ¿Estás seguro de que tienes la capacidad de conexión para transferir 5k de datos en 50ms, y mucho menos 12? He estado en circuitos privados de no utilización en todo el continente y he visto tiempos de ping superiores a 50 ms, y ping no transfiere 5k de datos.
¿Cómo mantendrá los dos servidores no relacionados sincronizados? Si realmente necesita una latencia inferior a 50 ms en todo el continente, el mejor caso teórico significa que tiene 12 ms para ejecutar algoritmos de sincronización. Incluso una consulta para verificar los datos en el otro servidor significa que está fuera de la ventana de 50 ms. Si los datos no están sincronizados, ¿cómo lo arreglarán? Teniendo en cuenta los tiempos anteriores, no veo cómo es posible sincronizar en menos de 50 ms.
Recomendaría revisar los requisitos de diseño fundamentales. Específicamente, ¿por qué este requisito? Los requisitos de latencia de 50 ms de ida y vuelta en todo el continente suelen ser signos de comercialización o falta de atención a los detalles. Apostaría a que si analiza los requisitos encontrará que esta ventana de 50 ms es excesiva e innecesaria. Si no es así, y la sincronización de datos es realmente importante (probable), alguien tendrá que determinar si el esfuerzo extra significativo para escribir el código de sincronización lo vale o incluso es posible mantener dentro de la ventana de 50 ms. La sincronización de datos de latencia sub-50ms entre continentes no es un problema simple.
Si no tiene necesidad de sincronización, ¿por qué no simplemente ejecutar un servidor?Puede usar un esclavo en el otro lado del continente para fines de recuperación. Por supuesto, eso todavía significa que, en el mejor de los casos, tiene 12 ms para obtener los datos por allí y viceversa. No contaría con 50ms operaciones de ida y vuelta + latencia + 5k/10k transferencia de datos en todo el continente.
Quiero agradecerle por tomarse el tiempo para escribir todo eso. Creo que la pregunta que se planteó tal vez se hizo para preguntar algo imposible (no estoy seguro) para alejar la idea de usar algo nuevo. El problema es que tenemos varias ubicaciones y queremos que los usuarios escriban en un máster cercano a ellas, luego tenemos un proceso para garantizar que haya consistencia en tiempo real (lo más rápido posible) entre ambos sitios. ¿Tiene alguna sugerencia que pueda encajar en este escenario? – DvideBy0
Preguntaría cuál es el aspecto más importante, las escrituras cercanas o las lecturas cercanas. Lo más rápido posible será un solo maestro y esclavos de lectura locales. ¿Eres intensivo en lectura o de escritura intensiva, o aproximadamente 50-50? Si ya tiene los sitios del centro de datos, pondría un maestro en funcionamiento y realizaría pruebas. Multi-maestro, especialmente en todo el continente es lejos de ser simple. Afortunadamente, en la mayoría de los casos no es realmente necesario. Me gustaría configurar un conjunto de prueba y explorarlo para validar el caso. No se centre en multimaestro si hay una forma más simple y sólida. Sospecho que 1Master y esclavos distribuidos trabajarán para usted. –