El laberinto de replicación de múltiples fuentes de GTID

En esta publicación de blog, analizamos cómo navegar por algunas de las complejidades de la replicación GTID de múltiples fuentes.

La replicación de GTID suele ser un verdadero desafío para los DBA, especialmente si tiene que ver con la replicación de GTID de varias fuentes. Hace un tiempo, me encontré con un entorno de cliente realmente interesante con fragmentos donde la replicación de MySQL 5.6 MIXED multi-master, multi-source, multi-threaded estaba activa. Este es un entorno muy complejo que tiene sus pros y sus contras, introduciendo riesgos tales como una compensación por los requisitos específicos del cliente.

Esta es la parte de instalación de este entorno:

Empecé a buscar en esta configuración cuando una declaración rompió la replicación entre db1 y db10. La replicación se interrumpe debido a una sentencia ejecutada en un esquema que no estaba presente db10. Esto también ha resultado en cambios que se originaron a partir de db1 para no ser empujado a caer db100 así como también db10ya que firmamos el hilo de replicación (para el canal db1).

Por otro lado, la replicación no se detuvo. db2 porque el esquema en cuestión estaba presente db2. replicación entre db2 y db20 también se rompió porque el esquema no estaba presente db20.

Resolver db1->db10 replicación, se inyectaron cuatro conjuntos de GTID db10.

Aquí hay algunas publicaciones de blog interesantes sobre cómo tratar/resolver problemas de replicación de GTID:

Después de inyectar los conjuntos de GTID, comenzamos la replicación nuevamente y todo salió bien.

Después de eso, tuvimos que comprobar db2->db20 replicación que, como ya he dicho, también se ha roto. En este caso, inyectando solo el primer GTID trx en db20 en lugar de todos los que causan problemas db10 fue suficiente!

Usted se estará preguntando cómo es esto posible. ¿Correcto? La respuesta es que el resto de ellos han sido replicados por db10 a db20aunque el canal no era el mismo.

Otra cosa extraña es el hecho de que incluso el subproceso de replicación para el db2->db20 El canal se ha detenido (roto), verifique el estado del esclavo db20 ha demostrado que Executed_Gtid_Set se movió a través de todos los canales también Retrieved_Gtid_Set ¡porque se ha detenido el descanso! Entonces, ¿qué estaba pasando aquí?

Esto despertó mi curiosidad, así que decidí investigar un poco más y crear escenarios sobre otras cosas extrañas que podrían suceder. Una cosa interesante fue sobre los filtros de replicación. En nuestro caso, pensé «¿Qué sucede en el siguiente escenario…?»

Digamos que escribimos una fila desde db1 a db123.table789. Esta fila se replica en db10 (digamos con el canal 1) y un db2 (digamos con el canal 2). En el canal 1, filtramos el db123.% mesas, en el canal 2 no. db1 escriba la fila y la entrada en el registro binario. db2 escribir la cola después de leer la entrada del registro binario y luego escribir la entrada en su propio registro binario y replicar este cambio en db20. Este cambio también se replica en db10. Así que ahora, adelante db10 (dependiendo de qué canal encuentre el GTID primero) se filtra en el canal 1 y se escribe en su propio registro de bin solo. startcommit con cualquier DDL / DML actual eliminado, o si se ha leído antes en el canal 2 (db1->db2 y luego db20->db10) entonces no se filtra y se ejecuta en su lugar. ¿Es esto correcto? ¡Por supuesto que no!

Puntos de interés

Puede encontrar respuestas a las preguntas anteriores en los puntos de interés que se enumeran a continuación. Aunque no está muy claro en la documentación oficial, esto es lo que sucede con la replicación de GTID y la replicación de GTID de múltiples fuentes:

  • Como sabemos, los conjuntos de GTID son únicos en todos los nodos de un clúster determinado. En la replicación de múltiples fuentes, Executed_Gtid_Set es común a todos los canales. Esto significa que, independientemente del canal de origen, cuando se ejecuta una transacción GTID, se registra en todos los canales». Executed_Gtid_Set. Aunque es lógico (cada base de datos es única, por lo que si un trx va a afectar una base de datos no debe restringirse a un solo canal independientemente del canal que use), la documentación no proporciona mucha información al respecto.
  • Cuando tenemos una replicación de varios niveles y fuentes múltiples, hay casos en los que los conjuntos de GTID que se originan en un maestro pueden terminar en un esclavo debido a las diferentes rutas de replicación. No está claro si aplica un algoritmo especial (aunque no parece que pueda ser uno), pero el método preferido parece ser FIFO. ¡El más rápido gana! Esto significa que los conjuntos de GTID pueden viajar al esclavo a través de diferentes canales, y está relacionado con la velocidad con la que los esclavos de nivel superior pueden realizar cambios. De hecho, la ruta realmente no importa porque solo ejecuta cada GTID trx una vez.
  • Los filtros de replicación son globales independientemente del canal. Esto significa que aplican cada filtro a todos los canales. Esto es normal ya que no podemos definir un filtro de replicación por canal. Para poder depurar tales casos, parece una buena idea agregar un pequeño retraso de replicación por canal.

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