Concepts
PHP Manual

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.

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 :

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.


Concepts
PHP Manual