Intégration du cache

Note: Version requise

Cette fonctionnalité requière l'utilisation de PECL/mysqlnd_ms 1.3.0-beta ou supérieure et de PECL/mysqlnd_qc 1.1.0-alpha ou supérieure. PECL/mysqlnd_ms doit être compilé pour supporter cette fonctionnalité. PHP 5.4.0 ou supérieure est requise.

Note: Clusters MySQL appropriés

Cette fonctionnalité est prévue pour une utilisation avec un serveur de réplication MySQL (copie primaire). Actuellement, aucun autre type de cluster MySQL n'est supporté. Les utilisateurs d'un tel cluster doivent contrôler PECL/mysqlnd_qc manuellement s'ils sont intéressés dans la mise en cache de requête côté client.

Le support des clusters de réplication MySQL (copie primaire asynchrone) est le principal but de PECL/mysqlnd_ms. Les esclaves d'un cluster de réplication MySQL peuvent ou non refléter les dernières mises à jour depuis le maître. Les esclaves sont asynchrones, et peuvent lagger derrière le maître. Une lecture depuis un esclave a une consistence éventuelle depuis une perspective cluster.

Le même niveau de consistence est offert par un cache local en utilisant une stratégie d'invalidation time-to-live (TTL). Des données courantes ou des données non mises à jour peuvent être servies. Eventuellement, les données recherchées depuis le cache peuvent ne pas être disponibles et la source du cache peut devoir être accédé.

En fournissant à la fois un esclage de réplication MySQL (secondaire asynchrone) et un cache local TTL, un niveau de service identique est fourni, et il est possible de remplacer de façon transparente un accès à une base de données distante par un accès au cache local afin d'améliorer les possibilités.

Depuis PECL/mysqlnd_ms 1.3.0-beta, le plugin est capable de contrôler de façon transparente PECL/mysqlnd_ms 1.1.0-alpha ou supérieure pour mettre en cache une requête en lecture seule si c'est explicitement autorisé via la configuration d'une qualité de service appropriée en utilisant la fonction mysqlnd_ms_set_qos(). Reportez-vous à la section Démarrage rapide pour un exemple de code. Les deux plugins doivent être installés, et PECL/mysqlnd_ms doit avoir été compilé pour supporter la fonctionnalité de cache, et enfin, PHP 5.4.0 ou supérieure doit être utilisé.

Les applications ont un contrôle total de l'utilisation du cache et peuvent demander la mise à jour des données à n'importe quel moment, si besoin. L'utilisation du cache peut être activée et désactivé lors de l'exécution du script. Le cache sera utilisé si la fonction mysqlnd_ms_set_qos() définit la qualité de service à une consistence éventuelle, et active l'utilisation du cache. L'utilisation du cache est désactivé en demandant un niveau de consistence supérieur, par exemple, une consistence de session (lecture de vos écritures). Une fois que la qualité de service revient à une consistence éventuelle, le cache peut de nouveau être activé.

Si la mise en cache est active pour une requête en lecture seule, PECL/mysqlnd_ms peut injecter une astuce SQL pour contrôler la mise en cache via PECL/mysqlnd_qc. Cela va modifier la requête SQL récupérée depuis l'application. Les processeurs SQL suivants sont supposés ignorer les astuces SQL. Une astuce SQL est un commentaire SQL. Les commentaires ne doivent pas être ignorés, par exemple, par le serveur de base de données.

Le TTL d'une entrée du cache est calculé pour chaque requête. Les applications définissent l'âge maximal des données qu'elles souhaitent récupérer en utilisant la fonction mysqlnd_ms_set_qos(). L'âge définit une limite supérieure approximative en secondes des données pouvant être retournées depuis le maître en tenant compte du lag.

La logique suivante est utilisée pour calculer le TTL courant si le cache est actif. La logique prend en compte le lag estimé de l'esclave pour choisir un TTL. Si, par exemple, il y a deux esclaves qui laguent de 5 et 10 secondes et que l'âge maximal autorisé est de 60 secondes, le TTL sera défini à 50 secondes. Notez également que la définission de l'âge ne dépassera pas le calcul estimé.

Vérifie si la requête est une requête en lecture seule. Si ce n'est pas le cas, aucune mise en cache ne sera demandée.
Si le cache est actif, vérifie si le lag de tous les serveurs esclaves configurés. Etablissement des connexions aux esclaves si aucune n'existe et que les connexions paraisseuses sont utilisées.
Envoi SHOW SLAVE STATUS à tous les esclaves. N'attends pas que le premier esclave réponde avant d'envoyer la demande au second. Les clients attendent souvent longtemps, aussi, tout est envoyé en même temps et l'analyse se fera dans un second temps.
On parcourt tous les esclaves. Pour chaque esclave, on attend sa réponse. On ne commence pas l'analyse du prochain esclave avant que le courant n'ait répondu. On vérifie Slave_IO_Running=Yes et Slave_SQL_Running=Yes. Si les deux conditions sont vraies, on récupère la valeur de Seconds_Behind_Master. Dans le cas d'une erreur, ou d'un échec sur l'une des conditions, on définit une erreur sur la connexion de l'esclave. Cela permet d'ignorer ces connexions pour le reste du filtrage de connexion.
Recherche de la valeur maximale de Seconds_Behind_Master depuis tous les esclaves qui ont passés les conditions précédentes. On soustrait la valeur depuis l'âge maximal fourni par l'utilisateur avec la fonction mysqlnd_ms_set_qos(). Le reste de cette soustraction sera utilisé comme TTL.
Ce filtrage va trier tous les esclaves. Ainsi, l'âge maximal est utilisé comme TTL, car le lag maximal trouvé vaut zéro. Il est tout à fait valide de trier tous les esclaves. Le filtre de balance de charge interne prendra le maître.
Injection des astuces SQL appropriées pour activer la mise en cache par PECL/mysqlnd_qc.
Traitement avec la connexion filtrée, i.e. applique les règles de balance de charge pour récupérer un esclave.
PECL/mysqlnd_qc est chargé après PECL/mysqlnd_ms par PHP. Aussi, il verra toutes les modifications de requêtes de PECL/mysqlnd_ms et mettra en cache la requête si il en a reçu l'instruction.

L'algorithme peut paraître impressionnant. SHOW SLAVE STATUS est une opération très rapide.En considérant un nombre de requêtes suffisants et les accès au cache par seconde, le coût de la vérification du lag des esclaves est largement inférieur au coût d'une décision du cache.

Les suggestions sur un meilleur algorithme sont bien entendues les bienvenues.