Pregunta

Tenemos nuestro principal servidor MySQL en City A. Tenemos la mayor parte de nuestro personal de servicio al cliente en City B. El personal se queja de que la conexión es demasiado lenta para el servidor. Las opciones son:

  1. Haz que salgan por Internet público en lugar de nuestro enlace directo entre las ciudades; De esa manera, Ping podría ser más largo, pero no compiten con el tráfico VoIP entre las ciudades

  2. Cluster la base de datos para que las escrituras y lecturas puedan ocurrir simultáneamente en servidores locales en ambas ciudades.

2 es muy preferible, pero como probablemente pueda ver por mi descripción, no tengo absolutamente ninguna idea de cómo implementarlo o incluso si es 'agrupación'. Lo mejor que pude encontrar para MySQL Cluster es que requeriría usar tablas NDB y prefiero no convertir toda nuestra base de datos a eso. ¿Cuáles son mis opciones aquí? Gracias.

¿Fue útil?

Solución

¿Qué tan separados (tiempo de ping) están las dos ciudades? 80 ms es lo que experimentamos en los Estados Unidos. No está mal.

Es posible escribir a ambos jefes de maestro maestro, pero tiene muchos puntos de dolor.

El clúster NDB permite caliente, pero (como usted dice) requiere alguna conversión.

Entonces, volviendo a lo que veo como la única solución viable: un solo maestro de escritura, además de cualquier cantidad de esclavos.

Una cosa que puede hacer que un maestro remoto sea doloroso es si la "unidad" de acción del usuario se traduce en muchas declaraciones SQL. Eso puede/debe resolverse (1) repensar el código para usar menos declaraciones (2) usar un procedimiento almacenado para encapsular tantas declaraciones SQL como sea posible, luego implementarlo en el maestro remoto.

Las lecturas (aparte de las "lecturas críticas") pueden/deben ir a un esclavo, detrás de un equilibrador de carga. Y algún mecanismo debe garantizar que las lecturas generalmente sean "locales".

Licenciado bajo: CC-BY-SA con atribución
No afiliado a dba.stackexchange
scroll top