La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

MySQL Cluster Cette présentation illustre la solution open source MySQL Cluster 7.1. Larchitecture MySQL Cluster 7.1 permet de répondre aux besoins suivants.

Présentations similaires


Présentation au sujet: "MySQL Cluster Cette présentation illustre la solution open source MySQL Cluster 7.1. Larchitecture MySQL Cluster 7.1 permet de répondre aux besoins suivants."— Transcription de la présentation:

1

2 MySQL Cluster Cette présentation illustre la solution open source MySQL Cluster 7.1. Larchitecture 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é dun nombre élevé de nœuds, - Répartition de la charge : sur lensemble 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. CaractéristiquesLimitesConclusion

3

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 quil ny 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 : cest 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 shared nothing 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 daccès aux données, il parse lordre SQL, détermine le coordinateur de transaction…cela peut être un serveur mysql ou une application exploitant lapi 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 seffectue 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 seffectue 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 dun 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 lexemple 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 quun nœud dans chaque node group est vivant, le cluster continue de fonctionner car lentièreté des données est disponible. Par contre si tous les nœuds dun node group tombent, le cluster sarrê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 lacheminement 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 quil 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 daccès Le nœud de données dispose de 4 méthodes daccè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 dun nœud Les serveurs dotés dune 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 dune sous partition principale (portion dune partition dont un nœud de données à la charge) et dune sous partition répliquée (dans le cas dun nombre de replicas à 2). Ce fonctionnement permet un accès parallélisé aux différentes sous partitions dune 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 lordre 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 dapplication (idem). …..on fini par contrôler le statut du cluster.

14 NDBINFO La base NDBINFO permet dobtenir en temps réel des informations sur létat de santé et les statistiques dutilisation du cluster. Parmi les informations les plus pertinentes ont peut citer lutilisation 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 dun nœud de données Il est possible dajouter un nœud à chaud puis de lancer une redistribution des données sur lensemble 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 lutilitaire 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 Lorsquun 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 dun recover le nœud de données récupère le plus récent LCP et applique les mises à jour des fichiers redo logs jusquau 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 : cest le checkpoint spécifique à un nœud de données. Lors dun 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 lensemble des nœuds. En résumé lors dun 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 dun 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

20 Quelques limites… Absence de contraintes dinté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 denregistrements 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 dune 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 damé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 dun cluster MySQL Cluster vers un autre ou vers dautres 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.)


Télécharger ppt "MySQL Cluster Cette présentation illustre la solution open source MySQL Cluster 7.1. Larchitecture MySQL Cluster 7.1 permet de répondre aux besoins suivants."

Présentations similaires


Annonces Google