Les filtres

Note: Version requise

Les filtres existent depuis mysqlnd_ms version 1.1.0-beta.

Filtres. Toutes les applications PHP utilisant un type de cluster de réplication MySQL ont besoin d'abord d'identifier un groupe de serveurs dans le cluster qui pourront exécuter une requête donnée avant que la requête ne soit exécutée sur un des candidats. En d'autres termes, une liste donnée de serveurs doit être filtrée pour n'en faire sortir qu'un.

Le processus de filtrage peut inclure l'utilisation d'un ou plusieurs filtres. Les filtres peuvent être chaînés. Ils sont exécutés dans l'ordre de leurs apparitions dans le fichier de configuration du plugin.

Note: Comparaison du chainage des filtres avec les tubes (pipes)

Le concept de chaînage des filtres peut être comparé à l'utilisation des tubes des utilitaires de ligne de commande d'un shell d'un système d'exploitation : un flux entrant est passé au processus, et transféré à la sortie. Puis, la sortie est passé comme entrée à la prochaine commande qui est connectée à la précédente en utilisant un opérateur pipe.

Les filtres suivants sont disponibles

• Filtre de balance de charge : random, roundrobin.
• Filtre de sélection : user, user_multi, quality_of_service.

Le filtre random implémente les stratégies random et random once. Round robin peut être configuré via le filtre roundrobin. La définition d'une fonction de rappel utilisateur peut être utilisée pour la sélection des serveurs avec le filtre user.Le filtre quality_of_service trouve des noeuds capables de répondre à un certain service, par exemple, "lit tes écritures" ou encore ne pas avoir plus de X secondes de retard sur le maitre.

Les filtres peuvent accepter des paramètres pour changer leurs comportements. Le filtre random accepte un paramètre optionnel sticky. Si définit à true, le filtre modifie la balance de charge de random à random once. Random sélectionne un serveur aléatoirement à chaque fois qu'une requête est exécutée. Random once sélectionne un serveur aléatoirement lors de la première requête et le ré-utilise pour toutes les autres requêtes PHP.

Une des plus grosses particularités des filtres est la possibilité de les chaîner. La puissance de ce concept n'est pas immédiatement visible car les filtres random, roundrobin et user ne sont supposés sortir pas plus d'un serveur. Si un filtre réduit la liste des candidats pour l'exécution d'une requête sur un seul serveur, il prend un sens limité en utilisant un serveur comme sortie pour les autres filtres pour une réduction future de la liste des candidats.

Un exemple d'une séquence de filtre qui va échouer:

• Requête à exécuter : SELECT 1 FROM DUAL. Passé à tous les filtres.
• Tous les noeuds configurés sont passés comme entrée au premier filtre. Nœuds maîtres : master_0. Nœuds esclaves : slave_0, slave_1
• Filtre : random, argument sticky=1. Sélectionne un esclave aléatoire à utiliser pour le reste des requêtes PHP. Sortie : slave_0.
• Sortie de slave_0 et la requête à exécuter est passée comme entrée pour le prochain filtre. Ici : roundrobin, liste de serveurs passé au filtre est : slave_0.
• Filtre : roundrobin. La liste des serveurs consiste en un seul serveur, round robin retourne toujours le même serveur.

Si vous tentez d'utiliser de telles séquences de filtres, le plugin peut émettre une alerte comme (mysqlnd_ms) Error while creating filter '%s' . Non-multi filter '%s' already created. Stopping in %s on line %d. Par la suite, une erreur appropriée sur le gestionnaire de connexion devrait être définie.

Il existe un second type de filtre : le multi filtre. Ce type ressort zéro, un ou plusieurs serveurs. Le filtre quality_of_service en est un exemple. Si la qualité de service est réglée avec une limite de retard des esclaves et que plus d'un esclave est victime de retard dans la limite, le filtre retourne alors plus d'un noeud. Un filtre multi doit être chainé avec un autre pour réduire la liste.

Voici une séquence de filtres avec quality_of_service suivi d'un filtre d'équilibre de charge.

• Requête à exécuter: SELECT sum(price) FROM orders WHERE order_id = 1. Passée à tous les filtres.
• Tous les noeuds configurés sont passés en entrée du premier filtre. Noeuds maitres: master_0. Noeuds esclaves: slave_0, slave_1, slave_2, slave_3
• Filtre: quality_of_service, règle: session_consistency ("lit tes écritures") Sortie: master_0
• Sortie master_0 et la requête à exécuter est passée en entrée du filtre suivant, un filtre roundrobin.
• Filtre: roundrobin. La liste des serveurs ne contient qu'un seul serveur. Round robin selectionne master_0.

Une séquence de filtres ne doit pas se terminer sur un filtre multi, sinon le plugin risque d'envoyer un avertissement du type (mysqlnd_ms) Error in configuration. Last filter is multi filter. Needs to be non-multi one. Stopping in %s on line %d. Aussi, une erreur sur la connexion risque d'arriver.

Note: Spéculation sur le futur: Filtres de réplication MySQL

Dans les futures versions, il devrait y avoir plus de filtres multi. Par exemple, il devrait exister un filtre table pour supporter le filtrage de réplication MySQL. Le filtre de réplication MySQL vous autorise de définir des règles où la base de données ou la table sera répliquée vers un noeud précis d'un cluster de réplication. Supposons que votre cluster de réplication consiste en 4 esclaves (slave_0, slave_1, slave_2, slave_3), 2 d'entre eux répliquent une base de données nommée sales (slave_0, slave_1). Si l'application requête la base de données slaves, l'hypothétique filtre table réduit la liste des serveurs possibles à slave_0, slave_1. En raison du fait que la sortie et que la liste des serveurs candidats contient plus d'un serveur, il est nécessaire et possible aux futures filtres de filtrer la liste des candidats, par exemple, en utilisant le filtre de balance de charge pour identifier un serveur pour l'exécution de la requête.