Ce billet est le premier d'une série de 5 articles sur Cluster MySQL écrite par Rémy Verger(auteur invité).

Je rappelle que ce billet est le dernier (et oui déjà) d'une série de 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

---

DUMP a chaud sur une base de données de type Cluster MySQL

La plus part des sociétés qui décide d'employer ce genre d'architecture pour leur base de données, pensent avant tout a la sauvegarde en ligne de leur données sans l'interruption de service. L’intérêt de MySQL Cluster est que les données sont donc toutes stockées en mémoire, ce qui rend donc possible ce processus de sauvegarde.

Une sauvegarde représente le contenu d'une base de données, à un moment donné. La sauvegarde contient 3 parties principales :

• Les méta-données (quelles tables existents, etc.)
• Les lignes des tables(les données )
• Un historique des transactions archivées

Chaque partie est stockée sur tous les noeuds qui participent à la sauvegarde.

Durant une sauvegarde, chaque noeud sauve ces données sur le disque, en trois fichiers :

BACKUP-<BackupId>.<NodeId>.ctl 

Le fichier de contrôle, qui contient les données de contrôle et les méta-données.

BACKUP-<BackupId>-0.<NodeId>.data 

Le fichier de données qui contient les lignes des tables.

BACKUP-<BackupId>.<NodeId>.log 

Le fichier de log, qui contient les transactions archivées.

Dans les lignes ci-dessus, <BackupId> est un identifiant pour la sauvegarde, et <NodeId> est l'identifiant du noeud qui a créé le fichier.

Meta data

Les méta-données sont consistuées des définitions de table. Tous les noeuds ont la même définition de table, sauvée sur le disque.

Table records

Les lignes sont sauvées par fragment. Chaque fragment contient un entête qui décrit à quelle table appartient les lignes. Après un groupe de ligne, il y a pied-de-page qui contient une somme de contrôle. Différents noeuds sauvent différents fragment durant la sauvegarde.

Committed log 

L'historique contient les transactions archivées, effectuée durant la sauvegarde. Seules les transactions impliquant les tables stockées sur le noeud sont stockées dans le log. Les différents noeuds de la sauvegarde sauvent différents logs, car ils abritent différents fragments de bases de données.

Utilisation du serveur de gestion pour une sauvegarde de cluster

Il faut suivre les étapes suivantes:

1. Lancez le serveur de management.
2. Exécutez la commande START BACKUP.
3. Le serveur de gestion vous indiquera ``Start of backup ordered''. Cela signifie que le serveur de management a envoyé la requête au cluster, mais qu'il n'a pas encore reçu de réponse.
4. Le serveur de gestion va indiquer ``Backup <BackupId> started'', où <BackupId> est l'identifiant de la sauvegarde. Cette information sera aussi enregistrée dans le log du cluster (à moins que cela ne soit configuré autrement). Cela signifie que le serveur a reçu des réponses, et que la sauvegarde a été faite. Cela ne signifie pas que la sauvegarde est complète.
5. Le serveur de gestion va indiquer que la sauvegarde est finie avec le message ``Backup <BackupId> completed''.

Utilisation du serveur pour annuler une sauvegarde :

1. Lancez le serveur de gestion.
2. Exécutez la commande ABORT BACKUP <BACKUPID>. Le numéro <BackupId> est l'identifiant de la sauvegarde, qui est inclut dans la réponse du serveur de gestion au moment de la création de la sauvegarde : ``Backup <BackupId> started''. L'identifiant est aussi sauvé dans le log du cluster (cluster.log).
3. Le serveur de gestion répond ``Abort of backup <BackupId> ordered''. Cela signifie qu'il a envoyé la requête au cluster, mais n'a pas encore re¸u de réponse.
4. Le serveur de gestion répond ``Backup <BackupId> has been aborted reason XYZ''. Cela signifie que le cluster a annulé la sauvegarde, et supprimé toutes les ressources reliées, y compris les fichiers.

Dans la partition /home de votre serveur noeud vous pouvez donc voir ceci . Un dossier Backup crée par le serveur de management, puis le numeros de la sauvegarde et les fichiers nécessaire a sa restauration.

Utilisation des processus serveurs MySQL par MySQL Cluster

mysqld est le processus traditionnel du serveur MySQL. Pour être utilisé avec MySQL Cluster, il doit être compilé avec le support des tables NDB. Si le binaire mysqld a été compilé correctement, le moteur de tables NDB Cluster est désactivé par défaut.

Pour activer le moteur NDB, il y a deux méthodes. Soit vous utilisez l'option --ndbcluster au démarrage, lorsque vous utilisez la commande mysqld ou bien, insérez une ligne avec ndbcluster dans la section [mysqld] de votre fichier my.cnf.

Un moyen facile pour vérifier que votre serveur supporte le moteur NDB Cluster est d'utiliser la commande SHOW ENGINES depuis un client mysql. Vous devriez voir la valeur YES dans la ligne de NDBCLUSTER. Si vous voyez NO, c'est que vous n'utilisez pas le programme mysqld compilé avec le support de NDB Cluster. Si vous voyez DISABLED, alors vous devez simplement activer le moteur dans votre fichier de configuration my.cnf.

Le serveur MySQL doit savoir comment lire la configuration du cluster. Pour accéder à cette configuration, il doit connaître 3 choses :

• Son propre numéro d'identifiant de noeud dans le cluster.
• Le nom d'hôte ou l'adresse IP où le serveur de gestion réside.
• Le port sur lequel se connecter au serveur de gestion.

Il y a actuellement trois moyens pour donner ces informations au processus mysqld. La méthode recommandée est de spécifier la chaîne de connexion de mysqld appelée ndb-connectstring, soit au démarrage de mysqld ou dans le fichier my.cnf.

Vous pouvez aussi inclure cette information dans un fichier appelé Ndb.cfg. Ce fichier doit résider dans le dossier de données de MySQL. Une autre solution est de configurer la variable d'environnement appelée NDB_CONNECTSTRING. La chaîne sera la même dans tous les cas : "[nodeid=<id>;][host=]<host>:<port>". Si aucune information n'est fournie, cette chaîne vaudra par défaut "host=localhost:2200".

ndb_mgmd.mysql.com est l'hôte où le serveur de gestion réside : il attend sur le port 2200.

Avec cette configuraiton, le serveur MySQL sera partie prenant du cluster MySQL, et accédera à la liste complète de tous les noeuds du cluster ainsi que leur statut. Il va se connecter à tous les noeuds de stockage, et sera capable d'utiliser chacun d'entre eux comme coordonnateur de transaction, ainsi que pour accéder aux données.

ndb_mgmd, le serveur de management

Le serveur de management est le processus qui lit le fichier de configuration du cluster, et distribue cette information à tous les noeuds qui le demande. Il gère aussi le log d'activité du cluster. Les clients de gestion s'y connectent et peuvent l'utiliser pour envoyer des commandes d'analyse et d'administration.

Si vous utilisez plusieurs serveurs de gestion, une chaîne de connexion doit être fournie, et tous les noeuds du cluster doivent explicitement spécifier leur identifiant.

• config.ini est le fichier de configuration du cluster. Il est créé par l'utilisateur et lu par le serveur de gestion.
• ndb_1_cluster.log est le fichier où les événements du cluster sont consignés. Les événements du cluster sont, par exemple : les jalons commencés ou complétés, les incidents de noeuds, les démarrages de noeuds, les niveaux d'utilisation de mémoire, etc.
• ndb_1_out.log est le fichier utilisé pour les entrées et sorties (stdout et stderr) lors de l'exécution du serveur de gestion comme démon. 1, dans ce contexte, est l'identifiant de noeud.
• ndb_1.pid est le fichier de PID utilisé lors de l'exécution du serveur de gestion comme démon. 1, dans ce contexte, est l'identifiant de noeud.
• ndb_1_cluster.log.1 , lorsque le log de cluster dépasse un millions d'octets, alors le fichier de log prend le nom indiqué ici, où 1 est le nombre de fichier de logs : si 1, 2 et 3 existent déjà, le suivant sera le numéro 4.

ndb_mgm, le client de gestion du cluster

Le dernier processus important à connaître est le client de gestion. Ce processus n'est pas nécessaire pour faire fonctionner le cluster. Son intérêt est que pouvoir vérifier le statut du cluster, de lancer les sauvegardes, et effectuer les autres activités d'administration. Il fournit un moyen d'accès et un jeu de commandes.

En fait, le client de gestion utilise une interface C qui donne l'accès au serveur de gestion : pour les utilisateurs experts, il est possible de programmer des processus spécifiques qui pourront effectuer des taches d'administration automatisées.

Commandes du client de gestion du Cluster

En plus du fichier de configuration central, le cluster peut aussi être contrôlé avec une interface en ligne de commande. La ligne de commande est disponible via un processus séparé de client de gestion du cluster. C'est l'interface principale de gestion du cluster.

Le client de gestion a les commandes suivantes de base. Ci-dessous, <id> indique un noeud de base de données (i.e. 21) ou le mot clé ALL qui indique que la commande doit être appliquée à tous les noeuds dans le cluster.

HELP

Affiche les informations sur toutes les commandes disponibles.

SHOW

Affiche les informations sur le statut du cluster.

<id> START

Lance le noeud de base de données identifié par <id>, ou bien tous les noeuds.

<id> STOP

Stoppe le noeud de base de données identifié par <id>, ou bien tous les noeuds.

<id> RESTART [-N] [-I]

Relance le noeud de base de données identifié par <id>, ou bien tous les noeuds.

<id> STATUS

Affiche les informations de statut du noeud de base de données identifié par <id> (ou de tous les noeuds avec ALL).

ENTER SINGLE USER MODE <id> 

Active le mode d'utilisateur unique, où seule l'API avec le noeud <id> est autorisée pour accéder au système de base de données.

EXIT SINGLE USER MODE

Quitte le mode d'utilisateur unique.

QUIT

Quitte le client de gestion du cluster.

SHUTDOWN

Arrête tous les noeuds du cluster, hormis les serveurs MySQL, puis s'arrête.

Conclusion

Note de Nicolargo: Merci encore à Remy pour cette série d'articles sur un sujet d'actualité vu le nombre croissant de données gérées par nos applications.