GTID o Identificador de transacción global fue introducido en MySQL 5.6.5. Un GTID es una identificación global única otorgada a todas las transacciones ejecutadas en un servidor de alojamiento MySQL habilitado para GTID. Los GTID son una combinación del UUID del servidor donde se ha confirmado una transacción en particular y el número de secuencia de esa transacción en ese servidor en particular. Esto hace que los GTID sean únicos a nivel mundial.

Replicación MySQL

La replicación basada en GTID es mucho más flexible en comparación con la replicación anterior basada en binlog. En una configuración basada en GTID, el esclavo no necesita un archivo binlog maestro ni una posición para iniciar la replicación. Obtenga más información sobre la replicación basada en GTID. En esta publicación de blog, analizaremos algunos problemas comunes de replicación de MySQL que se producen al implementar un conjunto de réplicas basado en GTID.

Transacciones errantes son transacciones que se aplican a uno o más esclavos que no necesitan replicarse en otros nodos. Pueden ser correcciones intermitentes aplicadas en el esclavo o escrituras accidentales en el esclavo por parte de una aplicación.

El problema con estas transacciones errantes surge cuando el esclavo que contiene una transacción errante es ascendido a maestro. En el caso de la replicación basada en GTID, esto causaría un problema. El nuevo maestro ahora se da cuenta de que los esclavos no han ejecutado la transacción errada. Puede pasar una de dos cosas:

(1) La transacción errada todavía está presente en el binlog del maestro y la enviará a los esclavos, esto puede corromper los datos o causar un error.
(2) La transacción no está presente en el binlog y, por lo tanto, no se puede enviar al esclavo, lo que provoca un error de replicación.

Prevención

Las transacciones erráticas se pueden prevenir activamente siguiendo estos pasos. Si tiene que aplicar una solución a un esclavo, una forma de mitigar las transacciones errantes es desactivar temporalmente el registro binario en el esclavo. Ejecutar sql_bin_log =0 antes de ejecutar la consulta errante debería funcionar. Más tarde puede habilitar binlog ejecutando sql_bin_log =1. Para evitar que cualquier aplicación escriba en esclavos, solo lectura debe estar habilitado en un servidor cuando está configurado como esclavo.

Detección

Detectar una transacción errada en un conjunto de réplicas de MySQL basado en GTID es fácil. MySQL almacena todos los GTID ejecutados en su tabla Esquema de rendimiento/Esquema de información según la versión de MySQL que esté utilizando. Tomar los GTID ejecutados del esclavo actual y restarlos de los GTID ejecutados en el maestro actual debería proporcionarle todas las transacciones errantes en ese esclavo en particular. Las utilidades como mysqlfailover o mysqlrpladmin también pueden ayudar a detectar transacciones erróneas.

Solución

Una vez que se ha detectado una transacción errada, hay dos formas de corregir los errores de replicación causados ​​después de una conmutación por error. Una forma es eliminar el GTID de la transacción errante del historial de ejecución del GTID esclavo. De esta forma, cuando el esclavo sea ascendido a maestro, la transacción errada no se replicará en todos los nodos. Otra forma de manejar la transacción errante es decirles a todos los demás esclavos que se salten la transacción errante. Eso incluiría insertar una transacción vacía con el mismo GTID que la transacción errante en todos los demás nodos en el conjunto de réplicas. Esto hará que todos los demás nodos piensen que ya han aplicado esta transacción y, por lo tanto, la omitirán. MySQL tiene una utilidad llamada Mysqlslavetrx dedicada a hacer esto. Esta utilidad se puede utilizar para insertar transacciones vacías con el GTID dado. Agregar transacciones vacías también puede tener otros usos, como se explica aquí.