BOUKRI KHALIL

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.

BOUKRI KHALIL
BOUKRI KHALIL
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.

BOUKRI KHALIL
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 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,
…

BOUKRI KHALIL
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.

BOUKRI KHALIL
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.

BOUKRI KHALIL
Une réplication synchrone
Afin de garantir le failover, une même Caractéristiques de la réplication :
donnée se trouve sur au moins deux nœuds
- Protocole 2PC
de données différents , et ce grâce au
mécanisme de réplication synchrone (via les - un thread joue le rôle du coordinateur
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.

BOUKRI KHALIL
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.

BOUKRI KHALIL
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.

BOUKRI KHALIL
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).

BOUKRI KHALIL
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.

BOUKRI KHALIL
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.

BOUKRI KHALIL
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.

BOUKRI KHALIL
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.

BOUKRI KHALIL
 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.

BOUKRI KHALIL
 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.

BOUKRI KHALIL
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

BOUKRI KHALIL
BOUKRI KHALIL
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),
 …

BOUKRI KHALIL
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.)

BOUKRI KHALIL