PASSAGE A L’ECHELLE MySQL CLUSTER 7.1

1. PASSAGE A L’ECHELLE MySQL CLUSTER 7.1

2. MySQL Cluster Cette présentation illustre la solution open source MySQL Cluster 7.1. L’architecture MySQL Cluster 7.1 permet de répondre aux besoins suivants : - La haute disponibilité : élimination du SPOF par redondances des données et failover, Le passage à l’échelle : possibilité d’un nombre élevé de nœuds, Répartition de la charge : sur l’ensemble des nœuds grâce au partitionnement & round robin. N.B. MySQL Cluster 7.1 (ou MySQL Cluster NDB 7.1) comprend le noyau MySQL Server 5.1 ainsi que le moteur de stockage NDB 7.1.

3. CARACTERISTIQUES

4. MySQL Cluster : Un cluster en shared nothing Shared nothing : Chaque nœud est autonome et possède son propre disque et sa mémoire. Cela implique qu’il n’y a aucun accès disques concurrents à partir de plusieurs nœuds. Dans le cas de MySQL Cluster, une réplication synchrone des mises à jour est effectuée entre les nœuds. Shared disk : Les nœuds possèdent chacun leur mémoire mais ils partagent une ou plusieurs ressources de stockage. Elle utilise un accès centralisé aux disques à partir de tous les nœuds. Tous les nœuds pouvant écrire de manière de concurrente via le cache disque, un mécanisme de synchronisation est nécessaire pour préserver la cohérence des données : c’est un manager de verrous distribués qui assume ce rôle. Shared everything : Les nœuds partagent une ou plusieurs ressources de stockage. Elle utilise un cache de données dit « commun » : un mécanisme (dit de cache fusion sur Oracle RAC) a été implémenté afin que la mémoire physiquement distincte de chaque nœud soit vue comme un tout par chaque nœud. Ce type de cluster permet un haut niveau de disponibilité car si un nœud est inaccessible les autres ne sont pas affectés, et de hautes performances car le cache de données commun permet de réduire les accès disques.

5. Un cluster en sharednothing MySQL Cluster consiste en trois types de nœuds différents, chacun d'eux offrant des services spécialisés au sein du cluster : Les nœuds d'applications (sql node) sont ceux par lesquelles passent toutes demandes d’accès aux données, il parse l’ordre SQL, détermine le coordinateur de transaction…cela peut être un serveur mysql ou une application exploitant l’api ndb. Les nœuds de gestion (management node) sont chargés de loguer les évènements du cluster, d'effectuer le rôle d'arbitre, arrêter/démarrer les nœuds de données, effectuer les sauvegardes…On utilise le client de gestion. Les nœuds de données (data node) sont les nœuds principaux du cluster et sont dotés des fonctionnalités suivantes : Stockage et gestion des données, Partitionnement , Réplication synchrone, …

6. Un partitionnement des données (1/2) La répartition des données s’effectue grâce au mécanisme de partitionnement (via les data nodes). Il peut être automatique (par défaut) ou manuel. Le partitionnement possède les caractéristiques suivantes : • Fragmentation horizontale : les partitions sont obtenues par répartition des lignes. • Par défaut s’effectue par hachage de la clé primaire (d'où obligation d'avoir une clé primaire, dans le cas contraire une colonne cachée en auto incrément est créée). Le partitionnement manuel permet de hacher sur une partie de la clé. • Chaque table a autant de partitions que de nœuds de données; Les nœuds sont regroupés dans des groupes de nœuds (node group) de sorte que les nœuds d’un même groupe de nœuds stockent les mêmes données. • Permet le parallélisme pour certaines opérations.

7. Un partitionnement des données (2/2) Dans l’exemple ci contre le cluster est configuré pour avoir 4 partitions et 2 réplicas, on appelle fragment primaire la partition qui est utilisée par les ordres SQL et le fragment secondaire la partition qui est utilisée lors du failover. Le terme de réplica est utilisé afin de déterminer le nombre de copies de fragments dont dispose le système.

8. Une réplication synchrone Afin de garantir le failover, une même donnée se trouve sur au moins deux nœuds de données différents , et ce grâce au mécanisme de réplication synchrone (via les data nodes). Pour la réplication il est essentiel d'utiliser le moteur de stockage NDBCluster. Tant qu’un nœud dans chaque node group est vivant, le cluster continue de fonctionner car l’entièreté des données est disponible. Par contre si tous les nœuds d’un node group tombent, le cluster s’arrête de fonctionner. Pour garantir la haute disponibilité il faut au minimum NoOfReplicas=2. • Caractéristiques de la réplication : • - Protocole 2PC • un thread joue le rôle du coordinateur

9. Le nœud de données Un nœud de données consiste en 4 threads qui exécutent un ensemble de composants logiciels appelés « block » : • TC (Transaction Coordinator) : il intervient au niveau global du système afin de traiter les requêtes distribuées, il est responsable de l’acheminement des requêtes vers le thread LQH. • LQH (Local Query Handler) : il intervient au niveau local du système (par opposition au TC) afin de traiter la transaction locale (sélections, mises à jour, ….) et coordonner la réplication 2PC avec le TC. Parmi les composants qu’il exécute on peut citer : • ACC (Access Manager) : il intervient dans la gestion des verrous et des indexes, • TUP (Tuple Manager) : il intervient dans le stockage des enregistrements , • … • SUMA (Subscription Manager) : il logue les évènements du cluster. • Transporter : il gère la communication entre les nœuds.

10. Les méthodes d’accès Le nœud de données dispose de 4 méthodes d’accès aux données : • Primary key access – accès par clé primaire (hash) • Unique Key access – accès par index unique (Hash) • Range scan – recherche par intervalle (index ordonné) • Full table scan – analyse complète de la table Contrainte importante : tous les indexes doivent pouvoir tenir en mémoire.

11. Parallélisme au sein du cluster Lorsqu'aucun index n'est utilisé pour accéder aux données. Dans ce cas, la requête est exécutée avec un scan de table (Full table scan). Le TC (Coordinateur de transaction) envoie en parallèle la requête à tous les nœuds, chaque local Query Handler (LQH) ayant la charge de lire entièrement son fragment primaire. Lorsque un index ordonné est utilisé. Dans ce cas, la requête est exécutée avec un range scan (Ordered index scan). Lors d'un Range scan le TC envoie en parallèle la requête à tous les noeuds, chaque local Query Handler (LQH) ayant la charge de lire son index T-Tree (index en mémoire qui ne contient que les données locales).

12. Parallélisme au sein d’un nœud Les serveurs dotés d’une architecture multi cœurs/processeurs permettent une scalabilité verticale au sein du système MySQL Cluster. Chacun des threads du gestionnaire LQH (Local Query Handler) est responsable d’une sous partition principale (portion d’une partition dont un nœud de données à la charge) et d’une sous partition répliquée (dans le cas d’un nombre de replicas à 2).  Ce fonctionnement permet un accès parallélisé aux différentes sous partitions d’une partition.

13. Configuration et démarrage On commence par la configuration : du cluster : config.ini sur le nœud de gestion, des nœuds SQL & data : my.cnf. On démarre dans l’ordre suivant : le nœud de gestion (il charge la configuration du cluster), les nœuds de données (il lit son fichier my.cnf et communique avec le nœud de gestion pour récupérer la configuration du cluster), le nœud d’application (idem). …..on fini par contrôler le statut du cluster.

14. NDBINFO La base NDBINFO permet d’obtenir en temps réel des informations sur l’état de santé et les statistiques d’utilisation du cluster. Parmi les informations les plus pertinentes ont peut citer l’utilisation de la mémoire de chaque nœuds de données (table memoryusage) ainsi que leur statut (table nodes). Cette base est créée au démarrage initial du serveur MySQL.

15. Ajout d’un nœud de données Il est possible d’ajouter un nœud à chaud puis de lancer une redistribution des données sur l’ensemble des nœuds. Les données doivent ensuite être réorganisées (ALTER TABLE ….REORGANIZE), en mémoire ou sur disque (Disk Data Tables). Par contre il est impossible de supprimer une partition.

16. Sauvegarde/Restauration On peut effectuer une sauvegarde à chaud via le client du nœud de gestion. Un backup est alors créé sur chaque des nœuds de, il consiste en 3 fichiers : les méta données de la base (nom & définition des tables du cluster), les données (de son propre nœud), un historique des transactions archivées effectuée durant la sauvegarde. Seules les transactions impliquant les tables stockées sur le nœud sont stockées dans le log. La restauration doit être exécutée pour chaque fichier de sauvegarde via l’utilitaire ndb_restore, c'est à dire aussi souvent qu'il y a de nœuds de données dans le cluster au moment de la création de la sauvegarde.

17. Reprise sur incident Lorsqu’un nœud est arrêté (arrêt planifié, problème hardware, problème software) il se trouve désynchronisé vis-à-vis des autres. Le système met en place un procédé de recover permettant de le rendre à nouveau disponible et synchronisé. Lors d’un recover le nœud de données récupère le plus récent LCP et applique les mises à jour des fichiers redo logs jusqu’au dernier GCP. Il contacte ensuite le(s) nœud(s) du même groupe de données pour savoir si des mises à jour ont été effectuées depuis le crash et va se resynchroniser. LCP : LocalCheckPoint : c’est le checkpoint spécifique à un nœud de données. Lors d’un LCP il y écriture des dirty blocks en mémoire vers le disque. GCP : GlobalCheckpoint : ce checkpoint intervient très régulièrement (fréquence de quelques secondes) de manière synchronisée sur l’ensemble des nœuds. En résumé lors d’un GCP il y a écriture synchronisé pour tous les nœuds de leur redo buffer en mémoire vers les redo logs sur disques.

18. Autres caractéristiques… • ~ In Memory Database (IMDB) • Split Brain géré par un arbitre • Deadlock géré par timeout • Echec d’un nœud détecté par heartbeat (contrôle circulaire) • Pas de failover du nœud SQL (nécessité de mettre en place une redondance) • Le cluster peut fonctionner sans le nœud de gestion • ISOLATION_LEVEL = read committed

19. LIMITES

20. Quelques limites… • Absence de contraintes d’intégrité référentielles, • Ne supporte pas les index FullText, • Impossibilité de supprimer une partition, • Aucune garantie que les informations de journalisation soient flushées sur disque au commit (le commit est effectué en mémoire). • Le nombre maximum d’enregistrements par partition est de 46M, • Le nombre maximum de nœuds de données est 48, • Le nombre maximum de nœuds est 63, • La taille maximum d’une ligne est 8K (sauf pour les BLOB), • …

21. CONCLUSION

22. Pour terminer… MySQL Cluster, de part ses limites et son architecture, est adapté à des applications a faible volumétrie, transactions simples, ….comme une application de type WEB, authentification, Portail, etc.. Une amélioration du système afin d’améliorer la disponibilité au moyen de la fonctionnalité de réplication par ligne (row based), il vous est possible de répliquer des éléments d’un cluster MySQL Cluster vers un autre ou vers d’autres bases de données SQL de type « non cluster ». La création des configurations maître/esclave suivantes peut être envisagée : • MySQL Cluster vers MySQL Cluster • MySQL Server (MyISAM, InnoDB, etc.) vers MySQL Cluster • MySQL Cluster vers MySQL Server (MyISAM, InnoDB, etc.)