Identifiants de transaction

Note: Version requise

L'injection d'identifiant de transaction coté client existe depuis mysqlnd_ms version 1.2.0-alpha. Les identifiants de transaction sont détectés en scrutant les appels API. C'est possible depuis PHP 5.4.0. Voyez aussi la gestion des transactions.

Depuis MySQL 5.6.5-m8, le serveur MySQL fournit des identifiants de transaction globaux. Cette nouvelle fonctionnalité est supportée par PECL/mysqlnd_ms 1.3.0-alpha et suivant. Aucune configuration n'est requise si vous choisissez d'utiliser la fonctionnalité interne du serveur.

Idées et émulation côté client

PECL/mysqlnd_ms peut effectuer de l'injection d'identifiant de transaction coté client, de manière transparente. Dans sa forme la plus basique, un identifiant de transaction est un compteur incrémenté à chaque transaction exécutée sur le maitre. Le compteur est sauvé dans une table sur le maitre. Les esclaves répliquent cette table.

Dans le cas d'un problème sur le maitre, un administrateur peut identifier facilement l'esclave le plus récent pour le passer en maitre. L'esclave le plus récent possède l'identifiant de transaction le plus élevé.

Les développeurs coté application peuvent demander au plugin l'identifiant de transaction (GTID) pour leur dernière opération d'écriture. Il peut alors être passé comme paramètre au filtre QoS dans le cadre de la consistence de session ("lit tes écritures"). Le filtre s'assure que toutes les lectures sont dirigées vers un hôte (maitre ou esclave) ayant répliqué la transaction référencée par le GTID.

Lorsque l'injection a été effectuée

Le plugin maintient la table GTID sur le maitre, de manière transparente. En mode autocommit, le plugin injecte un UPDATE avant d'exécuter les requêtes de l'utilisateur, pour chaque utilisation du maitre. EN mode transactionnel manuel, l'injection est effectuée avant l'appel à commit(). L'option de configuration report_error de la section GTID permet de contrôler si une transaction échouée doit annuler l'opération ou être ignorée silencieusement (cas par défaut).

Veuillez noter les versions de PHP requises pour la surveillance des transactions ainsi que leurs limites.

Limites

Les problèmes éventuels de l'injection d'identifiant de transaction ont des limites qui ne sont pas propres à PECL/mysqlnd_ms.

Les tables d'identifiants de transaction globale doivent être déployées sur tous les maîtres et les réplications.
Le GTID peut avoir des trous, seuls les clients PHP utilisant le plugin vont maintenir la table, pas les autres clients.
La détection des transactions n'est basée que sur les appels à l'API.
La détection des transactions coté client ne prend pas en compte les commits implicites. Certaines requêtes de MySQL causent un commit implicite.

Utilisation côté serveur de l'identifiant de transaction globale

Depuis PECL/mysqlnd_ms 1.3.0-alpha, les identifiants de transaction globale apportés par MySQL 5.6.5-m8 ou supérieure sont supportés. L'utilisation de cette fonctionnalité serveur supprime toutes les limitations vues précédemment. Reportez-vous au manuel de référence MySQL pour les limitations ainsi que les préconditions concernant l'utilisation des identifiants de transaction globale internes.

Choisir entre l'utilisation de l'émulation côté client ou la fonctionnalité interne du serveur est une question qui n'est pas en relation directe avec le plugin, aussi, la discussion restera superficielle. Il n'est pas actuellement prévu de supprimer l'émulation côté client et vous pouvez continuer de l'utiliser, si la solution interne du serveur n'est pas une option pour vous. Ce peut être le cas en environnement hétérogène comprenant de vieux serveurs MySQL ou, si une des limitations des solutions côté serveur n'est pas acceptable.

D'un point de vue applicatif, il y a une énorme différent dans l'utilisation de l'une ou l'autre des approches. Les propriétés suivantes diffèrent :

L'émulation côté client, comme vu dans le manuel, fournie une solution simple pour comparer un numéro de séquence pour les transactions globales. Les multi-maîtres ne sont pas traités pour conserver les exemples du manuel simples. La fonctionnalité côté serveur utilise une combinaison d'un identifiant de serveur et d'un numéro de séquence comme identifiant de transaction globale. La comparaison ne peut utiliser l'algèbre. A la place de cela, une fonction SQL doit être utilisé. Reportez-vous au manuel de référence MySQL pour plus de détails.
Les statistiques du plugin concernant l'identifiant de transaction globale ne sont disponibles qu'avec l'émulation côté client car elles surveillent l'émulation.

Note: Les identifiants de transaction globale dans les systèmes distribués

Les identifiants de transaction globale peuvent servir de différentes façon dans un contexte de systèmes distribués, comme un cluster de base de données. Les identifiants de transaction globale peuvent être utilisés, par exemple, comme identification système des transactions, comme tri global des transaction, comme mécanisme permettant de savoir si le serveur est toujours disponible, et pour vérifier le statut de réplication pour les serveurs de réplication. PECL/mysqlnd_ms, un driver côté client basé sur un sofware, ne focalise sur l'utilisation des GTIDs pour les tâches qui peuvent être gérées par le client, comme la vérification du statut de réplication des serveurs de réplication pour les configurations asynchrones de réplication.