IDs de transacciones globales

Nota: Requisitos de versión

La inyección de IDs de transacciones globales en el lado del cliente existe a partir de la versión 1.2.0-alpha de mysqlnd_ms. Los límites de una transacción son detectados monitorizando las llamadas a la API. Esto es posible a partir de PHP 5.4.0. Por favor, vea también Manejo de transacciones.

A partir de MySQL 5.6.5-m8, el servidor MySQL introduce los identificadores de transacciones globales internos. La característica del ID de transacciones global interno de MySQL es soportada por PECL/mysqlnd_ms 1.3.0-alpha o posterior. No es necesario la monitorización de los límites de transacciones en el lado del cliente ni ninguna configuración si se utiliza la característica del servidor.

Observe que todas las versiones de producción de MySQL 5.6 no proporcionan clientes con suficiente información para usar GTID para forzar la consistencia de sesión. En el peor de los casos, el complemento eligirá solamente el maestro.

Idea y emulación en el lado del cliente

PECL/mysqlnd_ms también realiza la inyección transparente de IDs de transacciones globales en el lado del cliente. En su forma más básica, un identificador de transacciones global es un contador que se incrementa en cada transacción ejecutada en el maestro. El contador se guarda en una tabla del maestro. Los esclavos replican la tabla del contador.

En caso de que falle un maestro, el adminstrador de la base de datos puede identificar fácilmente el esclavo más reciente para promoverlo como nuevo maestro. El esclavo más reciente tiene el identificador de transacciones más alto.

Los desarrolladores de aplicaciones pueden solicitar al complemento el identificador de transacciones global (GTID) para su última operación de escritura que tuvo éxito. El complemento devolverá un identificador que hace referencia a una transacción no más antigua que la última operación de escritura del cliente. Entonces, el GTID puede ser pasado como parámetro al filtro de calidad de servicio (QoS) como una opción para la consistencia de sesión. La consistencia de sesión se asegura de la lectura de sus escrituras. El filtro se asegura de que todas las lecturas son dirigidas al maestro o a un esclavo que haya replicado la escritura referida por el GTID.

Cuándo se realiza la inyección

El complemento mantiene de forma transparente la tabla del GTID del maestro. En el modo 'autocommit', el complemento inyecta una sentencia UPDATE antes de ejecutar las sentencias del usuario por cada uso del maestro. En el modo de transacción manual, la inyección se realiza antes de que la aplicación llame a commit() para cerrar la transacción. La opción de configuración report_error de la sección del GTID del fichero de configuración del complemento se utiliza para controlar si una inyección fallida debería abortar la operación actual o ser ignorada de forma silenciosa (lo predeterminado).

Por favor, observe los requisitos de versión de PHP para la monitorización de los límites de transacciones y sus limitaciones.

Limitaciones

La inyección de IDs de transacciones globales en el lado del cliente tiene defectos. Los problemas potenciales no son específicos de PECL/mysqlnd_ms, sino que son de naturaleza general.

Las tablas de IDs de transacciones globales deben ser desplegadas en todos los maestros y en todas las réplicas.
El GTID puede tener agujeros. Únicamente los clientes de PHP que utilicen el complemento mantendrán la tabla. Los demás clientes no lo harán.
La detección de los límites de las transacciones en el lado del cliente solamente está basada en llamadas a la API.
La detección de los límites de las transacciones en el lado del cliente no toma en cuenta la consigna implícita. Algunas setnencias SQL de MySQL causan una consignación implícita, por lo que no pueden ser revertidas.

Utilizar el identificador de transacciones global en el lado del servidor

Desde PECL/mysqlnd_ms 1.3.0-alpha se admite la característica del identificador de transacciones global interno de MySQL 5.6.5-m8 o posterior. El uso de esta característica del servidor elimna todas las limitaciones enumeradas arriba. Por favor, lea el Manual de Referencia de MySQL para conocer las limitaciones y las precondiciones del uso de identificadores de transacciones globales internos.

Si se utiliza la emulación del lado del cliente o la funcionalidad interna del servidor, es una cuestión que no está directamente relacionada con el complemento, por lo que no se trata en profundidad. No hay planes para eliminar la emulación del lado del cliente, por lo que se puede continuar usándola, si la solución del lado del servidor no es una opción. Éste podría ser el caso de entornos heterogéneos con un servidor MySQL antiguo, o si cualquiera de las limitaciones de la solución del lado del servidor no son acpetables.

Desde la perspectiva de las aplicaciones casi no hay diferencia en el uso de una estrategia u otra. Difieren las siguientes propiedades.

La emulación en el lado del cliente, como se muestra en el manual, utiliza un número de secuencia de transacciones global fácil de comparar. Los maestros múltiples no se tratan para no complicar los ejemplos del manual. La característica interna del lado del servidor utiliza una combinación de un identificador de servidor y un número de secuencia como identificador de transacciones global. La comparación no puede hacerse mediante álgebra numérica. En su lugar, se debe usar una función SQL. Por favor, lea el Manual de referencia de MySQL para más detalles. No se puede usar la característica interna del lado del servidor de MySQL 5.6 para asegurar la consistencia de sesión bajo ninguna circunstancia. No la utilice para la característica de calidad de servicio. Aquí se expone un ejemplo sencillo de por qué no proporcionará resultado fiables. Hay más casos límites que no se pueden cubrir con la funcionalidad limitada exportada por el servidor. Actualmente, los clientes solamente pueden preguntar al maestro de replicación de MySQL por una lista de todos los ID de transacciones globales ejecutadas. Si un esclavo está configurado para no replicar todas las transacciones, por ejemplo, porque están establecidos los filtros de replicación, el esclavo nunca mostrará el mismo conjunto de ID de transacciones globales ejecutadas. Aunque el esclavo podría haber replicado las escrituras de un cliente y podría ser un candidato para una lectura consistente, nunca será considerado por el complemento. En cuanto a la escritura, el complemento aprende del maestro que el historial de transacciones de servidores completo consiste en GTID=1..3. No hay forma de que el complemento pregunte por el GTID de la transacción de escritura en sí, digamos GTID=3. Se asume que el esclavo no replica la transacciones GTID=1..2, sino solamente GTID=3 debido a una característica de replicación. Entonces, el historial de transacciones de esclavos es GTID=3. Sin embargo, el complemento intenta encontrar un nodo que tenga un historial de transacción de GITD=1...3. Aunque el esclavo haya replicado la escritura del cliente y la consistencia de sesión podría alcanzarse al leer desde el esclavo, el complemento no lo considerará. Esto no es un fallo de la implementación del complemento, sino una laguna de la característica del lado del servidor. Observe que es este es un caso trivial para ilustrar el problema; existen otros más. En resumen, se sugiere no intentar usar los GTID internos de MySQL 5.6 para forzar la consistencia de sesión. Tarde o temprano, el equilibrado de carga dejará de funcionar de manera apropiada y el complemento dirigirá todas las peticiones de consistencia de sesión al maestro.
Las estadísticas de los IDs de transacciones globales están disponibles únicamente con la emulación en el lado del cliente debido a que monitorizan dicha emulación.

Nota: Identificadores de transacciones globales en sistemas distribuidos

Los identificadores de transacciones globales pueden servir para múltiples propósitos en el contexto de sistemas distribuidos, como un clúster de bases de datos. Los identificadores de transacciones globales se pueden usar para, por ejemplo, la identificación de transacciones en todo el sistema, el ordenameiento global de transacciones, el mecanismo de pulso, y la comprobación del estado de replicación de las réplicas. PECL/mysqlnd_ms, un software basado en un controlador del lado del cliente, enfoca el uso de GTIDs para tareas que puedan ser tratadas en el cliente, como la comprobación del estado de replicación de las réplicas para configuraciones de replicación asíncronas.