Niveaux de service et consistence

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:

• eventual consistency
• session consistency
• strong consistency

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.

• Consistence éventuelle, pas d'option passée: tous les maitres, tous les esclaves
• Consistence de session, pas d'options passée: tous les maitres
• Consistence forte (pas d'option possible): tous les maitres

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.