MySQL dispone al fin de identificadores globales de transacción

Por Néstor Chacón
Sysadmin de OpenSistemas

De manera similar a MariaDB con Gallera cluster y Percona con su XtraDB Cluster, Oracle ha implementado un identificador global de transacción (GTID en adelante) en la versión 5.6 de MySQL.

Un GTID es un identificador único compartido por todos los miembros de un cluster maestro-esclavo que se genera en el nodo maestro tras confirmarse una transacción (tras hacer un commit) y está compuesto por una dupla numérica separada por dos puntos, la primera parte de la dupla corresponde al identificador del origen de la transacción, la uuid del servidor maestro y la segunda parte es un identificador numérico de la operación que se ha realizado de tal manera que su aspecto es el siguiente: 3E11FA47-71CA-11E1-9E33-C80AA9429562:23

También podemos encontrarnos al ejecutar un show master status con una expresión del tipo 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-23 que indica de manera resumida todas las operaciones que se ha llevado a cabo.

Las ventajas de usar GTID son varias, para empezar, la replicación es síncrona a nivel de transacción, esto significa que no se da el commit por válido hasta que todos los nodos esclavos no han replicado la operación. De esta manera, nos evitamos el tener varios esclavos en momentos diferentes, mejorando la integridad de los datos y facilitando la elección de un nuevo maestro en caso de desastre.

Además, ya no hace falta especificar el fichero del log binario, ni su posición. Basta ahora con usar el argumento MASTER_AUTO_POSITION=1 dentro del CHANGE MASTER

Por supuesto, también tiene algunas contrapartidas que hay que analizar antes:

  • No se pueden realizar actualizaciones que impliquen tablas no transaccionales y tablas transaccionales dentro de la misma transacción.
  • CREATE TABLE … SELECT no está soportado.
  • CREATE TEMPORARY TABLE y DROP TEMPORARY TABLE sólo pueden usarse fuera de cualquier transacción y con la opción autocommit=1

Para evitar estas operaciones se pueden evitar arrancando el servidor con la opción enforce-gtid-consistency. Por otra parte, estas limitaciones son relativamente fáciles de soslayar reescribiendo un poco el sql.

El uso de GTID no es una solución de clustering completa, como tampoco lo es el uso de la forma tradicional de replicación maestro-esclavo, simplemente porque esa no es su función. Es, eso sí, un eslabón importante sobre el que se puede apoyar el resto de la arquitectura.

Oracle también ha proporcionado una serie de herramientas, entre ellas mysqlrpladmin y mysqlfailover que permiten añadirle más inteligencia al conjunto. Con la primera herramienta, podemos descubrir que esclavo es el más apropiado para promocionarse a maestro, promocionar un nodo o degradar otro, etc. es en definitiva una herramienta más que interesante para administrar el cluster manualmente o para integrarla con otras soluciones, como pacemaker. Con la segunda herramienta, tenemos una solución interesante que se encarga de monitorizar los nodos del cluster y de promocionar un nuevo maestro en caso de desastre, también permite la ejecución de scripts, antes, durante y después de la promoción de un nuevo maestro.

En resumen, hoy por hoy, no existe una solución libre que sea completa, sin embargo, disponemos ya de los elementos para poder construirla. En OpenSistemas estamos trabajando en la creación de un agente para pacemaker que integre la gestión de la replicación maestro-esclavo con GTID para uno de nuestros clientes más importantes.