Replicación de grupos de MySQL: impacto parcial del rendimiento de fallas en la red

En esta serie de blogs de dos partes, quería cubrir algunos escenarios de conmutación por error con replicación de grupo. En la primera parte, discutiré algunos comportamientos interesantes y la degradación del rendimiento que descubrí mientras escribía estas publicaciones. En la segunda parte, mostraré varios escenarios de conmutación por error y demostraré cómo Group Replication maneja cada situación.

El entorno de prueba es muy básico, una replicación de grupo de tres nodos (mysql1, mysql2, myslq3) en MySQL 8.0.19 con la configuración predeterminada. mysql2 es el Primary nodo.

En este escenario, estaba experimentando una falla parcial de la red cuando un nodo se separa del principal, pero otros nodos aún pueden ver.

Pensar mysql3 pierde el quórum y abandona el clúster, pero no lo hace. Dentro del clúster, todos los nodos están en constante comunicación entre sí, no solo el hablante principal mysql3 pero también mysql1 hablar con mysql3.

Si solicitamos el estado del clúster desde el primario, dirá que mysql3 es inaccesible.

Pero si le preguntamos al status quo mysql1 dirá que todo está bien:

Para mí, esto es un poco confuso, ya que les pregunto a dos miembros del mismo clúster y reportan diferentes estados, me gustaría ver el mismo estado del clúster en todos los nodos.

Pero ¿qué significa eso?

¿Puedo incluso escribir el clúster? Será mysql3 ¿Quieres hacer nuevos cambios? Para responder a estas preguntas, hagamos algunas pruebas simples.

Creé una tabla simple:

Ahora empiezo el siguiente ciclo en el primario:

Será fácil ingresar el nombre de host tantas veces como sea posible. Deje esto en blanco.

Abrí dos conexiones ssh, una a mysql2 (primaria) y otra a mysql3 y ejecuté el siguiente bucle:

/

nada mysql2 Imprimirá cuántas líneas se insertaron en mysql2 y mysql3 por segundo. mysql3 Corté la red entre

mysql3 mysql3 # iptables -A INPUT -s mysql2 -j DROP; iptables -A SALIDA -s mysql2 -j DROP mysql2Después, mysql1 siempre son los cambios, pero ¿cómo? No puede conectarse mysql2 . Pero todavía es capaz de conectarse mysql3que actuará como una especie de nodo de relevo entre mysql3 y . Esto suena bien porque incluso en el caso de una interrupción parcial de la red, aún podemos usarlo porque recibe los cambios. Sin embargo, este comportamiento no está documentado en ninguna parte. Así que no sé cómo funciona debajo del capó. lo abrí

informe de error

para actualizar la documentación. Degradación grave del rendimiento Sin embargo, también he notado que hay una grave degradación del rendimiento debido a esto. Cuando todos los nodos estaban conectados, pude ingresar de 60 a 80 filas por segundo. Tan pronto como corté la red, ese número se redujo a 2-5 inserciones por segundo, eso es

80-90% mysql2 degradaciones Eso podría tener un impacto severo en el rendimiento de cualquier aplicación, lo que significa que con Group Replication incluso interrupciones parciales de la red, o una regla de Iptables implementada incorrectamente, etc. podría causar problemas de producción. mysql1 Debido a que está mal documentado, no puedo estar seguro de por qué sucede esto. En la replicación de grupo, es suficiente para la mayoría reconocer transacciones, por lo que en teoría,

y sería suficiente para que no podamos explicar esta degradación con la latencia de la red debido al salto adicional. yo tambien abri uno

informe de error

por lo tanto, eso ya está confirmado. mysql3 ¿Cómo funciona esto con Percona XtraDB Cluster? Percona XtraDB Cluster se basa en Galera, que es otra solución de agrupación en clústeres para MySQL. En Galera, este comportamiento es bien conocido; un nodo puede actuar como un nodo de retransmisión incluso entre centros de datos. Repetí las mismas pruebas en un clúster PXC8 de tres nodos. Cuando corto la red entre el nodo primario (donde escribo) y hubo un intervalo de 3 segundos hasta que el clúster recalculó la vista del clúster y redirigió el tráfico, después de lo cual todo volvió a la normalidad allí mysql3 no medible mysql1impacto en el rendimiento,

31 mysql214:13:22

Además, en PXC8, todos los nodos también informan el mismo estado del clúster.

.

Conclusiones Debido a que la replicación grupal y la implementación y el enfoque de Galera son diferentes, puede ver que el impacto en el rendimiento también es diferente. Galera tiene una mejor tolerancia a los problemas de red que Group Replication. Publicaré una publicación de blog mucho más larga, que también tratará otros escenarios de conmutación por error/desastre.

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