
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.
MySQL mysql2: 3306 ssl JS> cluster.status(); {«clusterName»: «my_innodb_cluster», «defaultReplicaSet»: {«name»: «predeterminado», «primario»: «mysql2-T1: 3306», «ssl»: «DESHABILITADO», «estado»: «OK_NO_TOLERANCE», «statusText»: «El clúster no tolera todos los errores. 1 miembro no está activo», «topology»: {«mysql1-T1: 3306»: {«address»: «mysql1-T1: 3306», «mode»: » R/O «,» readReplicas «: {},» replicationLag «: null,» role «:» HA «,» status «:» ONLINE «,» version «:» 8.0.19 «},» mysql2 -T1 : 3306 «: {» dirección «:» mysql2-T1: 3306 «,» modo «:» R/W «,» readReplicas «: {},» replicationLag «: null,» role «:» HA «, «status «: «EN LÍNEA», «versión»: «8.0.19»}, «mysql3-T1: 3306»: {«dirección»: «mysql3-T1: 3306», «modo»: «n/a», «readReplicas «: {}, «role»: «HA», «shellConnectError»: «Error MySQL 2003 (HY000): no se puede conectar al servidor MySQL en ‘mysql3-T1’ (110)», «estado»: «INALCANZABLE», «versión»: «8.0.19»}}, «topologyMode»: «Single-Primary»}, «groupInformationSourceMember»: «mysql2-T1: 3306»
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 dieciséis 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
mysql mysql2:3306 SSL JS > grupo.estado(); { «nombre del clúster»: «mi_innodb_cluster», «Conjunto de réplicas predeterminado»: { «primer nombre»: «defecto», «primario»: «mysql2-T1: 3306», «ssl»: «DISCAPACITADO», «estado»: «OK_NO_TOLERANCIA», «texto de estado»: «El clúster no tolera ninguna falla. 1 miembro no está activo», «topología»: { «mysql1-T1: 3306»: { «habla a»: «mysql1-T1: 3306», «modo»: «R/O», «Leer réplicas»: {}, «Retraso de replicación»: nada, «papel»: «DECIR AH», «estado»: «EN LÍNEA», «versión»: «8.0.19» }, «mysql2-T1: 3306»: { «habla a»: «mysql2-T1: 3306», «modo»: «R/W», «Leer réplicas»: {}, «Retraso de replicación»: nada, «papel»: «DECIR AH», «estado»: «EN LÍNEA», «versión»: «8.0.19» }, «mysql3-T1: 3306»: { «habla a»: «mysql3-T1: 3306», «modo»: «n / A», «Leer réplicas»: {}, «papel»: «DECIR AH», «shellConnectError»: «Error de MySQL 2003 (HY000): no se puede conectar al servidor MySQL en ‘mysql3-T1’ (110)», «estado»: «RETRACTABLE», «versión»: «8.0.19» } }, «Modos de topología»: «primario único» }, «Grupo de miembros de fuente de información»: «mysql2-T1: 3306» |
Pero si le preguntamos al status quo mysql1
dirá que todo está bien:
MySQL mysql1: 3306 ssl JS> cluster.status(); {«clusterName»: «my_innodb_cluster», «defaultReplicaSet»: {«name»: «predeterminado», «principal»: «mysql2-T1: 3306», «ssl»: «DESHABILITADO», «estado»: «OK», «statusText»: «El clúster está EN LÍNEA y puede tolerar hasta UNA falla»., «topología»: {«mysql1-T1: 3306»: {«dirección»: «mysql1-T1: 3306», «modo»: » R / O «,» readReplicas «: {},» replicationLag «: null,» role «:» HA «,» status «:» ONLINE «,» version «:» 8.0.19 «},» mysql2-T1: 3306 «: {» dirección «:» mysql2-T1: 3306 «,» modo «:» R/W «,» readReplicas «: {},» replicationLag «: nulo,» rol «:» HA «,» estado «: «EN LÍNEA», «versión»: «8.0.19»}, «mysql3-T1: 3306»: {«dirección»: «mysql3-T1: 3306», «modo»: «R/O», «readReplicas»: {}, «replicationLag»: null, «role»: «HA», «status»: «ONLINE», «version»: «8.0.19»}}, «topologyMode»: «Single-Primary»}, » groupInformationSourceMember «:» mysql2-T1: 3306 «
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 dieciséis 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
mysql mysql1:3306 SSL JS > grupo.estado(); { «nombre del clúster»: «mi_innodb_cluster», «Conjunto de réplicas predeterminado»: { «primer nombre»: «defecto», «primario»: «mysql2-T1: 3306», «ssl»: «DISCAPACITADO», «estado»: «OK», «texto de estado»: «El clúster está EN LÍNEA y puede tolerar hasta UNA falla»., «topología»: { «mysql1-T1: 3306»: { «habla a»: «mysql1-T1: 3306», «modo»: «R/O», «Leer réplicas»: {}, «Retraso de replicación»: nada, «papel»: «DECIR AH», «estado»: «EN LÍNEA», «versión»: «8.0.19» }, «mysql2-T1: 3306»: { «habla a»: «mysql2-T1: 3306», «modo»: «R/W», «Leer réplicas»: {}, «Retraso de replicación»: nada, «papel»: «DECIR AH», «estado»: «EN LÍNEA», «versión»: «8.0.19» }, «mysql3-T1: 3306»: { «habla a»: «mysql3-T1: 3306», «modo»: «R/O», «Leer réplicas»: {}, «Retraso de replicación»: nada, «papel»: «DECIR AH», «estado»: «EN LÍNEA», «versión»: «8.0.19» } }, «Modos de topología»: «primario único» }, «Grupo de miembros de fuente de información»: «mysql2-T1: 3306» |
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:
CREATE TABLE `lab` (` id` int NOT NULL AUTO_INCREMENT, `hostname` varchar (20) DEFAULT NULL,` created_at` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY` idx_created` ( ))) MOTOR = InnoDB
CREAR MESA `laboratorio` ( ‘identificación’ En t NADA AUTOINCREMENTO, «nombre de host». varchar(20) DEFECTO NULO, `creado_para` tiempo de datos DEFECTO FECHA Y HORA ACTUAL AL ACTUALIZAR FECHA Y HORA ACTUAL, CLAVE PRIMARIA (‘identificación’), LLAVE `idx_creado` (‘creado_para’) ) MOTOR=InnoDB |
Ahora empiezo el siguiente ciclo en el primario:
mientras que cierto; hacer mysql -usbtest -pxxxxx -P3306 -h127.0.0.1 -e «INSERTAR EN sysbench.lab (nombre de host) VALORES (@@ nombre de host)»; hecho 2>/dev/null
mientras cierto;hacer mysql –prueba usb –xxxx –P3306 –h127.0.0.1 –mi «INSERTAR EN sysbench.lab (nombre de host) VALORES (@@ nombre de host)»; hecho 2>/desarrollador/nada |
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:
mientras sea verdad; haga mysql -BN -usbtest -pxxxxx -P3306 -hmysql2 -e «seleccione ‘mysql2’, cuente
ahora () de sysbench.lab donde created_at ENTRE ahora () – INTERVALO 1 segundo Y ahora () «; dormir 1; hecho 2> / dev / null mientrascierto; hacer mysql– BN– prueba usb– xxxx– P3306– hmysql2– mi«seleccione ‘mysql2’, cuente ahora () de sysbench.lab donde create_at ENTRE ahora () – INTERVALO 1 segundo Y ahora () « ;dormir 1 ;hecho2>/desarrollador |
/
nada mysql2
Imprimirá cuántas líneas se insertaron en mysql2 y mysql3 por segundo. mysql3
Corté la red entre
y
usando iptables:mysql3 # iptables -A ENTRADA -s mysql2 -j DROP; iptables -A SALIDA -s mysql2 -j DROP |
mysql3 mysql3
# iptables -A INPUT -s mysql2 -j DROP; iptables -A SALIDA -s mysql2 -j DROP mysql2
Después, mysql1
siempre son los cambios, pero ¿cómo? No puede conectarse mysql2
. Pero todavía es capaz de conectarse mysql3
que 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 mysql1
impacto en el rendimiento,
estaba recibiendo todos los cambios
: mysql3 62 2020-03-31 14:13:12 mysql3 65 2020-03-31 14:13:13 mysql3 67 2020-03-31 14:13:14 mysql3 69 3-13: 13 mysql3 69 2020-03-31 2020-03-31 14:13:16 mysql3 0 2020-03-31 14:13:17 mysql3 0 2020-03-31 14:13:18 mysql3 0 2020-03-31 194-03: 13 03-31 14 : 13: 20 mysql3 71 2020-03-31 14:13:21 mysql3 72 2020-03-31 14:13:22 mysql3622020–03 – 31 14:13:12 mysql3sesenta y cinco2020–03 – 31 14:13:13 mysql3672020–03 – 31 14:13:14 mysql3692020–03 – 31 14:13:15 mysql3472020–03 – 31 14:13:16 mysql302020–03 – 31 14:13:17 mysql302020–03 – 31 14:13:18 mysql302020–03 – 31 14:13:19 mysql3412020–03 – 31 14:13:20 mysql3712020–03 – 31 14:13:21 mysql3722020–03 – |
31 mysql2
14: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.