Note: Version requise
Les niveaux de service ont été ajoutés dans mysqlnd_ms version 1.2.0-alpha. mysqlnd_ms_set_qos() requiert PHP 5.4.0 ou plus récent.
Le plugin peut être utilisé avec différents types de clusters MySQL. Différents clusters vont délivrer différents niveaux de service à l'application. Les niveaux de services peuvent être classés par niveau de concistence des données qu'ils proposent. Le plugin reconnait:
En fonction de la manière dont le cluster est utilisé, il est possible d'avoir des niveaux de service plus hauts que celui par défaut. Par exemple, une lecture depuis un esclave MySQL asynchrone est éventuellement consistente. Ainsi, on peut dire que le niveau de consistence d'un cluster de réplication MySQL est éventuelle, cependant, si le maitre est seulement utilisé pour lire et écrire durant une session, on a une consistence de session ("lit tes écritures"). PECL mysqlnd 1.2.0 abstrait les détails concernant le choix d'un noeud approprié de la couche de service sur-jascente de l'utilisateur.
Les niveaux de service peuvent être ajoutés via le filtre qualify-of-service dans le fichier de configuration des plugins et pendant l'exécution au moyen de la fonction mysqlnd_ms_set_qos().
Les différents niveaux de service sont définis comme suit.
La consistence éventuelle est le niveau de service par défaut proposé par un cluster asynchrone comme la réplication MySQL classique. Une opération de lecture sur un noeud peut éventuellement retourner une données à jour, ou pas. La consistence est éventuelle.
La consistence de session est proposée lorsque le client peut toujours lire ses écritures. Un cluster de réplication MySQL asynchrone peut fournir la consistence de session si les clients utilisent toujours le maitre après la première écriture ou n'interrogent jamais un esclave qui n'a pas encore répliqué la donnée écrite.
Le plugin voit la consistence forte comme le fait que tout client puisse toujours voir des données écrites des autres clients. C'est le cas par défaut avec le cluster MySQL ou tout autre type de cluster proposant une distribution synchrone des données.
Paramètres des niveaux de service
Les consistences éventuelle et de session acceptent des paramètres.
La consistence éventuelle est le service proposé par la réplication classique MySQL.
Par défaut, tous les noeuds peuvent être éligibles à la lecture. Un paramètre optionnel
age
peut être utilisé pour filtrer les noeuds qui ont un certain retard
en secondes sur le maitre. Le plugin utilise SHOW SLAVE STATUS
pour mesurer le retard. Voyez le manuel de référence de MySQL pour plus d'informations sur
la précision et la fiabilité de la commande SHOW SLAVE STATUS
.
La consistence de session ("lit tes écritures") accepte un paramètre optionnel
GTID
permettant d'autoriser la lecture pas seulement sur le maitre, mais
aussi sur un esclave qui a répliqué la donnée, par son identifiant de transaction.
Ainsi, dans la réplication asynchrone, les lectures peuvent être équilibrées sur des esclaves
tout en assurant une consistence au niveau session.
Vous devez utiliser pour cela L'injection d'identifiant de transaction coté client.
Avantages de la nouvelle approche
La nouvelle approche dépasse l'utilisation d'astuces SQL et l'option
master_on_write
sur certains axes. Si une application qui tourne avec
une réplication MySQL asynchrone ne peut accepter de données non fraiches sur certaines
lectures, il est plus simple de laisser le plugin choisir le noeud approprié que de
préfixer toutes ses requêtes d'astuces SQL pour forcer l'utilisation du maitre. Aussi,
le plugin peut selectionner des esclaves dans ce cas.
L'option master_on_write
fait en sorte que le plugin choisisse le maitre
après la première écriture (consistence de session). Dans certains cas, la consistence de
session pourrait n'être utile que pour certaines lectures, et non toute la session courante.
De ce fait, master_on_write
pourrait engendrer plus de lectures sur le
maitre que nécessaire. Dans de tels cas, il est mieux de vouloir un niveau de consistence plus
haut que celui par défaut, juste pour certaines lectures le nécessitant. Une fois les lectures
passées, le niveau de consistence peut retomber à la normale. Changer de niveau de service
n'est possible qu'avec mysqlnd_ms_set_qos().
Considerations de performance
Une réplication MySQL ne peut indiquer aux clients quels esclaves sont capables de délivrer tel ou tel niveau de consistence. Ainsi, dans certains cas, les clients doivent requêter les esclaves pour connaitre leur statut. PECL mysqlnd_ms exécute de manière transparente les requêtes necéssaires, mais cette opération est lourde, elle est exécutée si la consistence éventuelle est combinée avec une limite d'âge (retard de l'esclave), ou si la consistence de session est combinée avec un identifiant de transaction.
Si la concistence éventuelle est combinée avec une limite d'âge, le plugin selectionne
le noeud pour chaque requête. Si c'est une écriture, tous les maitres sont candidats, les
esclaves ne sont pas vérifiés. Si c'est une lecture, le plugin exécute
SHOW SLAVE STATUS
sur tous les esclaves, les candidats sont ceux qui
répondent Slave_IO_Running=Yes
,
Slave_SQL_Running=Yes
et qui ont
Seconds_Behind_Master
inférieur ou égal à l'âge maximum demandé.
Dans le cas d'une erreur SQL, le plugin envoie un message d'erreur mais ne considère pas
la connexion comme mauvaise, l'erreur ne permet pas au plugin d'écarter tel ou tel noeud.
Si la consistence de session est combinée à un identifiant de transaction global, le plugin
exécute la requête SQL avec fetch_last_gtid
équivalant à la section
global_transaction_id_injection
du fichier de configuration du plugin.
En version 1.2.0, aucune optimisation supplémentaire n'est effectuée concernant les requêtes en arrière plan. Les versions futures pourraient embarquer de telles optimisation, en fonction des demandes utilisateur.
Si aucun paramètre ou option n'est précisé, aucun SQL n'est nécessaire. Dans ce cas, le plugin considère tous les noeuds comme suit.
Etranglement
La qualité d'un filtre de service peut être combinée avec les identifiants globaux de transaction pour limiter les clients. L'étranglement va réduire la charge en écriture sur le maître en ralentissant les clients. Si une consistence de session est demandée, et que les identifiants globaux de session sont utilisés pour vérifier le statut d'un esclave, la vérification peut être effectuée de deux façons différentes. Par défaut, un esclave est vérifiée et écartée immédiatement s'il ne correspond pas aux critères d'une consistence de session. Alternativement, le plugin peut attendre pour attrapper un esclave pour le maître qu'une consistence de session soit possible. Pour activer l'étranglement, vous devez définir l'option de configuration wait_for_gtid_timeout.