Gran obstáculo para la conmutación por error basada en GTID

Escribí anteriormente sobre el nuevo protocolo de replicación que viene con GTID en MySQL 5.6. Debido a este nuevo protocolo de replicación, puede crear sin darse cuenta transacciones erróneas que pueden convertir cualquier falla en una pesadilla. Vemos los problemas y las posibles soluciones.

En breve

  • Las transacciones incorrectas pueden causar todo tipo de corrupción de datos/errores de replicación cuando fallan.
  • La detección de transacciones errantes se puede hacer con el GTID_SUBSET () y GTID_SUSTRATO () funciones
  • Si encuentra una transacción errante en un servidor, realice una transacción vacía con el GTID errante en todos los demás servidores.
  • Si utiliza una herramienta de conmutación por error, asegúrese de que pueda detectar transacciones erróneas. Al momento de escribir, solo mysqlfailover y mysqlrpladmin de MySQL Utilities puede hacer eso.

¿Qué son las transacciones erróneas?

En pocas palabras, las transacciones se ejecutan directamente en un esclavo. Por lo tanto, existen solo en un esclavo específico. Esto podría deberse a un error (la aplicación escribió en un esclavo en lugar de escribir en el maestro) o podría deberse al diseño (necesita tablas adicionales para los informes).

¿Por qué crear problemas que no existían antes de los GTID?

Las transacciones errantes existen para siempre. Sin embargo, debido al nuevo protocolo de replicación para la replicación basada en GTID, pueden tener un impacto significativo en todos los servidores si un esclavo que tiene una transacción errónea se promociona como nuevo maestro.

Compare lo que sucede en esta configuración maestro-esclavo, primero con la replicación basada en posición y luego con la replicación basada en GTID. A es el maestro, B es el esclavo:

Como era de esperar, la base de datos mydb no se crea en A.

mydb se ha vuelto a crear en A debido al nuevo protocolo de replicación: cuando A se conecta a B, intercambian su propio conjunto de GTID ejecutados y el maestro (B) envía cada transacción faltante. Aquí está create database declaración.

Como puede ver, el principal problema con las transacciones erróneas es que cuando fallan, puede ejecutar transacciones «procedentes de la nada» que pueden corromper silenciosamente sus datos o romper su replicación.

¿Cómo te enteras?

Si el maestro está corriendo, es bastante fácil con el GTID_SUBSET () función. Dado que todos los scripts deben ir al maestro, los GTID ejecutados en cualquier esclavo siempre deben ser un subconjunto de los GTID ejecutados en el maestro. Por ejemplo:

Hum, parece que el esclavo ha realizado más transacciones que el maestro, esto indica que el esclavo ha realizado al menos 1 transacción errada. ¿Podemos saber el GTID de estas transacciones? Por supuesto, usamos GTID_SUSTRATO ():

Esto significa que el esclavo tiene 2 transacciones erróneas.

Ahora bien, ¿cómo podemos verificar transacciones erróneas si el maestro no está funcionando (ya que el maestro se ha caído y queremos que falle uno de los esclavos)? En este caso, seguiremos estos pasos:

  • Verifique todos los esclavos para ver si han ejecutado transacciones que no se encuentran en otro esclavo: esta es la lista de posibles transacciones erróneas.
  • Elimine todas las transacciones originales del maestro: ahora tiene una lista de las transacciones erróneas de cada esclavo.

Algunos de ustedes pueden preguntarse cómo pueden averiguar qué transacciones provienen del maestro porque no están disponibles: SHOW SLAVE STATUS le proporciona el UUID maestro que se usa en los GTID de todas las transacciones que provienen del maestro.

¿Cómo te deshaces de ellos?

Esto es bastante fácil, pero puede ser tedioso si tiene muchos esclavos: simplemente inyecte una transacción vacía en todos los demás servidores con el GTID de la transacción errante.

Por ejemplo, si tiene 3 servidores, A (maestro), B (esclavo con una transacción errante: XXX: 3) y C (esclavo con 2 transacciones errantes: YYY: 18-19), inyectará las siguientes transacciones vacantes en pseudocódigo:

Conclusiones

Si desea cambiar a la replicación basada en GTID, asegúrese de verificar si hay transacciones erróneas antes de que cambie la topología de replicación planeada o inesperada. Y tenga especial cuidado si utiliza una herramienta que reconfigura la replicación por usted: en el momento de escribir este artículo, solo mysqlrpladmin y mysqlfailover de MySQL Utilities puede advertirle si está intentando realizar un cambio de topología inseguro.

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