PASSAGE A L

1
PASSAGE A LECHELLE MySQL CLUSTER 7.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.

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 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 transactioncela 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
  sauvegardesOn 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 NoOfReplicas2.

• 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
LIMITES
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.)