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.

Veuillez noter que toutes les versions de production de MySQL 5.6 ne fournissent pas de clients avec suffisamment d'informations pour utiliser les GTIDs pour renforcer la consistence de sessions. Dans ce cas, le plugin choisira seulement le maître.

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 fonctionnalités internes côté serveur de MySQL 5.6 ne peuvent être utilisées pour assurer la consistence de sessions dans toutes les circonstances. Ne les utilisez donc pas dans le cas de la qualité de service. Voici un exemple simple montrant des résultats non fiables. Il y a plusieurs cas non pris en charge en raison des fonctionnalités limitées proposées par le serveur. Actuellement, les clients peuvent demander au service maître de réplication MySQL la liste de toutes les IDs de transactions globaux exécutées. Si un esclave est configuré pour ne pas répliquer toutes les transactions, par exemple, en raison de la définition de certains filtres, alors l'esclave ne montrera jamais le même jeu d'IDs de transactions globaux exécutées. Malgré le fait que l'esclave peut avoir répliqué les écritures des clients, et qu'il peut être candidat pour une lecture consistente, il ne sera jamais retenu par le plugin. Pendant l'écriture, le plugin apprend du maître que l'historique des transactions terminées des serveurs est GTID=1..3. Il n'y a aucun moyen pour le plugin de demander le GTID de la transaction d'écriture, soit GTID=3. Imaginez qu'un esclave ne réplique pas les transactions GTID=1..2 mais seulement GTID=3 en raison d'une fonctionnalité de la réplication. Alors, l'historique de transaction de l'esclave sera GTID=3. Cependant, le plugin tente de trouver un noeud qui a un historique de transactions de GITD=1...3. Malgré le fait que l'esclave a répliqué les écritures des clients et que la consistence de session a été réalisée pendant la lecture depuis l'esclave, il ne sera pas considéré par le plugin. Ceci n'est pas la faute de l'implémentation du plugin, mais d'une fonctionnalité côté serveur. Notez que cet exemple est trivial, et ne permet que d'illustrer le propos, mais il y a d'autres cas. En résumé, vous ne devriez pas utiliser les GTIDs internes à MySQL 5.6 pour renforcer la consistence de session. Tôt ou tard, la balance de charge arrêtera de fonctionner normalement, et le plugin va diriger toutes les requêtes de consistence de sessions vers le maître.
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.