Clústeres síncronos de WAN: Tratamiento de latencia mediante concurrencia

En este blog, discutiremos cómo usar la competencia para ayudar con la latencia de WAN cuando se usan clústeres síncronos.

Problema de latencia de WAN

Nuestros clientes a menudo nos piden ayuda o consejo con problemas de agrupamiento de WAN. Históricamente, la solución habitual para implementar MySQL WAN es tener el sitio principal en un centro de datos y el sitio de respaldo en espera en otro centro de datos (replicándose desde el principal de forma asíncrona). En estos días, sin embargo, existe un gran deseo de emplear las soluciones de replicación síncrona disponibles para MySQL. Estas soluciones incluyen cosas como Galera (es decir, Percona XtraDB Cluster) o la replicación de grupo MySQL recientemente lanzada. Esta tendencia se atribuye al hecho de que estas soluciones son menos problemáticas y brindan procedimientos de caída y caída más automatizados. Pero también es por eso que las empresas quieren escribir en ambos centros de datos simultáneamente.

Desafortunadamente, la confiabilidad y la latencia del enlace WAN hacen que la solución de replicación síncrona sea un gran desafío. En muchos casos, estos desafíos obligan a los centros de datos geográficamente separados a replicar de forma asíncrona.

Desde el punto de vista de los requisitos, la documentación oficial de los fundadores de Galera tiene una relación WAN recomendaciones y algunas opciones dedicadas (como segmentos), como se describe en la publicación de blog de Jay. Pero las implementaciones de WAN son absolutamente posibles, e incluso una Anunciado opción, en Galera. El equipo de replicación de MySQL Group, sin embargo, parece desalienta tales casos de usocomo podemos leer:

La replicación de grupo está diseñada para implementarse en un entorno en clúster donde las instancias del servidor están muy cerca unas de otras y se ven afectadas tanto por la latencia de la red como por el ancho de banda.

Remedio

Si bien quizás sea obvio para algunos, me gustaría señalar una dependencia simple que podría ser una solución viable en algunas implementaciones que generan una latencia de red significativa. Esta solución es competencia! Cuando se enfrenta al problema de una salida de escritura limitada debido a la latencia de una comisión de transacción, puede emplear más subprocesos de secuencias de comandos. Usando conexiones separadas a MySQL, generalmente puede hacer esto cometen más transacciones al mismo tiempo.

Demostremos con resultados de ejemplo basados ​​en un caso de prueba muy simple. Probé Percona XtraDB Cluster (con replicación de Galera) y MySQL Group Replication. Sin embargo, configuré un clúster mínimo de tres nodos, ejecutándose como contenedores Docker en el mismo host (simulando una WAN). Para esta configuración, la latencia es de unos 0,05 ms de media. Entonces, introduje una latencia de red artificial de 50ms y 100ms en una de las interfaces de red del nodo. Luego repetí las mismas pruebas usando instancias de VirtualBox VM, ejecutándolas en un servidor completamente diferente. Los resultados fueron muy similares. El comando para simular latencia de red adicional es:

Para retrasar el ping a otros nodos en el clúster:

La prueba es muy simple: realice 500 pequeñas transacciones de inserción, cada una insertando una sola fila (pero esto es menos relevante ahora).

Para probar, utilicé un simple comando mysqlslap:

es una sola tabla simple:

Curiosamente, sin una mayor latencia, la misma prueba dura mucho más en el clúster de Group Replication, aunque, de forma predeterminada, Group Replication funciona con activación.
group_replication_single_primary_modey discapacitados
group_replication_enforce_update_everywhere_checks. En teoría, debería ser una operación más ligera, desde el punto de vista de las «comprobaciones de coherencia de datos». Incluso con latencias de tipo WAN, Percona XtraDB Cluster parece ser un poco más rápido en esta prueba en particular. Estos son los resultados de las pruebas para las tres latencias de red diferentes:

Clúster XtraDB latencia / segundo
Los cables 100ms 50ms 0,05 ms
1 51,671 25,583 0.268
4 13,936 8,359 0.187
8 7.84 4.18 0.146
dieciséis 4,641 2,353 0.13
32 2.33 1.16 0.122
64 1,808 0.925 0.098
GRAMO latencia / segundo
Los cables 100ms 50ms 0,05 ms
1 55,513 29,339 5,059
4 14,889 7,916 2,184
8 7,673 4,195 1,294
dieciséis 4.52 2,507 0.767
32 3,417 1,479 0.473
64 2,099 0.809 0.267

Utilicé los mismos parámetros de InnoDB para ambos clústeres, cada nodo en un contenedor Docker separado o en una VM de Virtual Box. Los resultados de pruebas similares podrían diferir mucho en los sistemas de producción reales, donde más núcleos de CPU proporcionan mejores condiciones multiconcurrentes.

Ni siquiera fue idea mía comparar Galera con Group Replication, sino más bien demostrar que la misma competencia por la dependencia del rendimiento de escritura se aplica a ambas tecnologías. Es posible que me falten algunos ajustes del lado de la replicación del grupo, por lo que no estoy reclamando ningún ganador verificado aquí.

Solo para proporcionar algunos detalles más, utilicé Percona XtraDB Cluster 5.7.16 y MySQL con Group Replication 5.7.17.

Una nota importante: cuando espera que una mayor competencia proporcione un mejor rendimiento, debe asegurarse de que la competencia no esté limitada por los parámetros del servidor. Por ejemplo, hay que tener cuidado
innodb_thread_concurrency (Usé 0, así que ilimitado),
trabajadores_paralelos_esclavos para GR es
wsrep_slave_threads para Galera (entre otros sobre la operación IO, etc.).

Aparte del «ajuste de la competencia», que podría implicar cambios en la aplicación, si no un rediseño de la arquitectura, ciertamente hay más optimizaciones posibles para el entorno WAN. Por ejemplo:

https://www.percona.com/blog/2016/03/14/percona-xtradb-cluster-in-a-high-latency-network-environment/ (para lidiar con la latencia)

y:

https://www.percona.com/blog/2013/12/19/replicacion-automatica-relaying-galera-3/

para ahorrar/minimizar el uso de la red
binlog_row_image=mínimo y otras variables.

Pero estos están fuera del alcance de esta publicación. Espero que esta simple publicación te ayude a lidiar con eso. velocidad de la luz ¡mejor! ⁇

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario