Introduction

Fonctionnalités clés

Les fonctionnalités clés de PECL/mysqlnd_ms sont les suivantes.

• Transparent et facile d'utilisation.

  • supporte toutes les extensions PHP MySQL.

  • Support de SSL.

  • Une API cohérente.

  • très légère (voire aucun) modification de l'application nécessaire, suivant le scénario d'utilisation.

  • Connexions paresseuses : les connexions entre le maître et les esclaves ne sont pas ouvertes avant qu'une requête SQL n'est exécutée.

  • Optionnel : utilisation automatique du maître après la première écriture dans une requête web, afin de réduire tant que possible l'impact du lag de la réplication.

• Peut être utilisé avec n'importe quelle solution de cluster MySQL.

  • Réplication MySQL : La séparation des lectures/écritures est faîte par le plugin. Focus en premier lieu sur le plugin.

  • Cluster MySQL : La séparation des lectures/écritures peut être désactivée. Configuration de plusieurs maîtres possibles.

  • Solutions tierces : le plugin est optimisé pour la réplication MySQL mais peut être utilisé avec tout autre type de solution de cluster MySQL.

• Stratégies de séparation de la lecture et de l'écriture

  • Détection automatique des SELECT.

  • Support des astuces SQL permettant d'écraser le comportement courant.

  • Définie par l'utilisateur.

  • Peut être désactivé, par exemple, lors de l'utilisation de clusters synchrones comme MySQL Cluster.

• Stratégies de balance de charge

  • Round Robin : choisit un esclave différent à la façon round robin pour chaque sélection d'esclave.

  • Aléatoire : choisit de façon aléatoire un esclave pour chaque requête dirigée vers un esclave.

  • Aléatoire unitaire : choisit un esclave aléatoirement, une seule fois pour toutes les requêtes dirigées vers un esclave le temps de la requête web.

  • Définit par l'utilisateur. L'application peut enregistrer des fonctions de rappel avec mysqlnd_ms.

  • PHP 5.4.0 ou supérieur : Consistence des transactions lors de l'utilisation d'appel API pour uniquement contrôler les transactions.

  • Equilibrage de charge pondéré : les serveurs peuvent se voir assigner différentes priorités, par exemple, pour diriger plusieurs requêtes vers une machine plus performante au lieu de les diriger vers une machine moins performante ; ou bien pour préférer les machines les plus proches afin de réduire la latence.

• ID de transaction global

  • Émulation côté client. Rends la gestion manuelle d'un serveur maître qui tombe, et la promotion d'un esclave plus simple avec les clusters asynchrones, comme par exemple avec MySQL Replication.

  • Support des identifiants de transaction globale interne de MySQL 5.6.5 ou supérieure.

  • Support de l'utilisation des identifiants de transaction pour identifier les esclaves asynchrones à jour pour la lecture lorsque la consistence de la session est requis.

  • Etranglement : optionnellement, le plugin peut attendre qu'un esclave devienne "synchrone" avant de continuer.

• Niveaux de service et de consistences

  • Les applications peuvent éventuellement demandées de forts niveaux de consistence pour les services et les session pour les connexions. Les noeuds du cluster appropriés seront recherchés automatiquement.

  • L'accès à la consistente éventuelle d'un esclave de réplication MySQL peut être remplacé par un accès transparent au cache local rapide, et ce, afin de réduite la charge du serveur.

• Partitionnement et fragmentation

  • Les serveurs d'un cluster de réplication peuvent être organisés en groupes. Les astuces SQL peuvent être utilisées manuellement pour diriger les requêtes vers un groupe spécifique. Le groupage peut être utilisé pour partitionner les données, ou pour résoudre les problèmes des hotspots avec des mises à jour.

  • Les filtres de réplication MySQL sont supportés via la table de filtrage.

Limitations

Le mécanisme interne de séparation lecture/écriture est très basique. Chaque requête qui commence par SELECT est considérée comme une requête en lecture à envoyer à un serveur esclave MySQL. Toutes les autres requêtes (y compris les requêtes de type SHOW) sont considérées comme des requêtes en écriture à envoyer vers le serveur maître MySQL. Le comportement interne peut être écraser en utilisant les astuces SQL ou une fonction de rappel définie par l'utilisateur.

La séparation lecture/écriture ne prend pas en considération les requêtes multiples. Elles sont considérées comme une seule et unique requête. La décision de l'endroit où doit être exécutée la requête sera prise suivant le début de la chaîne de requête. Par exemple, si mysqli_multi_query() est utilisé pour exécuter une requête multiple comme SELECT id FROM test ; INSERT INTO test(id) VALUES (1), la requête sera redirigée vers un serveur esclave car elle commence par SELECT. La requête INSERT, qui fait également partie de la requête multiple, ne sera pas redirigée vers le serveur maître.

Note:

Les applications doivent tenir compte des conséquences des commutations de connexion effectuées pour la balance de charge. Veuillez vous rapporter à la documentation sur la file de connexion et la commutation, la gestion des transactions, la bascule, la balance de charge et la séparation lecture/écriture avec attention.

A propos du nom

Le raccourci mysqlnd_ms provient de mysqlnd master slave plugin. Le nom a été choisi pour une démonstration rapide du concept. Au début, les développeurs n'avaient pas prévus de continuer à utiliser le code de base.