Page de manuel de référence MySQL 5.0

Un Cluster MySQL est un groupe de processus qui s'exécutent sur plusieurs serveurs MySQL, des nœuds NDBCluster, et des processus d'administration, ainsi que des processus d'accès spécialisés. Tous ces programmes fonctionnent ensemble pour former un Cluster MySQL. Lorsque les données sont stockées dans le moteur NDBCluster, les tables sont réparties sur les nœuds NDBCluster. Ces tables sont directement accessibles depuis tous les autres serveurs MySQL faisant partie du Cluster. Par conséquent, si une application met à jour une ligne, tous les autres serveurs le verront immédiatement.

Les données stockées dans le moteur de table de MySQL Cluster peuvent être dupliquées, et sont capables de gérer une indisponibilité d'un nœud sans autre impact que l'annulation des transactions qui utilisaient ces données. Cela ne devrait pas être un problème, car les applications transactionnelles sont écrites pour gérer les échecs de transaction.

En plaçant MySQL Cluster en Open Source, MySQL rend les hautes performances, haute disponibilité et grands trafics accessibles à tous ceux qui en ont besoin.

MySQL Cluster est constitué de trois types de programmes différents :

premièrement, un jeu de processus serveur MySQL. Ce sont des serveurs MySQL traditionnels, avec le nouveau moteur de table NDBCluster qui autorise l'accès aux tables en cluster ;
le second type de processus est représenté par les nœuds de stockage de NDBCluster. Ces processus contiennent les données stockées dans MySQL Cluster. Les données de MySQL Cluster sont réparties entre les différents nœuds du cluster, et sont aussi doublées dans le cluster ;
le troisième type de processus est les processus d'administration. Ces processus sont utilisés pour gérer la configuration du cluster.

Nous appelons ces processus de cluster les nœuds du cluster. Mettre en place la configuration du cluster implique la configuration de chaque nœud dans le cluster, et la configuration de chaque moyen de communication entre les nœuds du cluster. MySQL Cluster est actuellement configuré avec le prérequis que les nœuds sont homogènes en termes de puissance processeur, espace mémoire et largeur de bande. De plus, pour activer un point de configuration, il a été décidé de placer toute la configuration du cluster dans un seul fichier de configuration.

Les processus d'administration gèrent le fichier de configuration du cluster, et les logs. Tous les nœuds dans le cluster contactent le serveur d'administration pour lire leur configuration : ils doivent donc savoir où le serveur d'administration réside en premier lieu. Lorsqu'un événement pertinent survient dans un moteur de stockage, il est transféré au serveur d'administration qui l'écrit dans le log.

De plus, il y a un nombre arbitraire de clients connectés au cluster. Ils sont de deux types. D'abord, les clients MySQL normaux, qui ne sont pas spécifiques à MySQL Cluster. MySQL Cluster est accessible à partir des applications MySQL écrites en PHP, Perl, C, C++, Java, Ruby, etc. Deuxièmement, les clients d'administration. Ces clients accèdent au serveur d'administration, et émettent des commandes pour lancer ou arrêter correctement des nœuds, lancer ou arrêter la trace serveur (pour les versions de débogage), pour afficher la configuration courante, voir l'état des nœuds du cluster, afficher les versions et nœuds, lancer les sauvegardes, etc.

Cette section est un guide qui décrit comment planifier l'installation, configurer et faire fonctionner un cluster MySQL viable. Contrairement aux exemples de la section Section 16.4, « Configuration de MySQL Cluster »Configuration de MySQL Cluster, le résultat de ces procédures est un cluster MySQL fonctionnel, qui dispose des fonctionnalités minimales pour assurer la disponibilité et la sauvegarde des données.

Dans cette section, nous allons couvrir : le matériel et les logiciels nécessaires ; les problèmes réseau ; l'installation de MySQL et du cluster ; la configuration ; le démarrage, l'arrêt et le redémarrage du cluster MySQL ; le chargement de données dans une base d'exemple ; l'exécution de requêtes.

Hypothèses de base

Ce guide part des hypothèses suivantes.

Nous allons configurer un cluster de quatre nœuds, chacun sur un hôte distinct, et chacun des hôtes étant relié au réseau avec une adresse IP fixe, via une carte Ethernet classique, comme ceci :

Nœud	Adresse IP
nœud de gestion (MGM)	192.168.0.10
Serveur MySQL (SQL)	192.168.0.20
Serveur de stockage (NDBD) « A »	192.168.0.30
Serveur de stockage (NDBD) « B »	192.168.0.40

Cela est peut-être plus clair sur le schéma suivant :

Note : par souci de simplicité et de robustesse, nous allons utiliser les adresses IP numériques dans ce guide. Cependant, si la résolution DNS est disponible sur votre réseau, il est aussi possible d'utiliser les noms d'hôtes plutôt que les IP lors de la configuration du cluster. Alternativement, vous pouvez aussi utiliser le fichier /etc/hosts de votre système d'exploitation ou son équivalent pour fournir un système de résolution de noms.

Chaque hôte est un ordinateur de bureau Intel, avec une distribution générique Linux sur le disque, dans une configuration standard, et sans aucun service inutile. Le cœur du système et un client standard TCP/IP doivent être suffisants. De même, par souci de simplicité, nous allons supposer que les systèmes de fichiers des hôtes sont tous identiques. Dans le cas où ils ne le sont pas, vous devrez adapter les instructions en fonction des situations.
Des cartes 100 mégabits ou gigabits Ethernet sont installées sur chaque machine, avec les bons pilotes pour les cartes, et chaque hôte est connecté au réseau via un routeur standard, comme un switch. Toutes les machines doivent utiliser des cartes avec le même débit, c'est-à-dire que toutes les machines du cluster sont en 100 mégabits, ou bien en gigabit. Le cluster MySQL fonctionnera sur un réseau 100 mégabits, mais les cartes gigabit fourniront de meilleures performances.
Notez que le cluster MySQL n'est pas prévu pour fonctionner sur un réseau avec une connectivité inférieure à 100 mégabits. Pour cette raison, entre autres, faire fonctionner un cluster MySQL sur un réseau public ou via Internet risque de ne pas réussir, et n'est pas recommandé.
Pour les données de tests, nous allons utiliser la base de données world qui est disponible en téléchargement sur le site de MySQL AB. Comme cette base de données prend peu d'espace, nous pouvons fonctionner avec des machines ayant 256 Mo de RAM, ce qui doit être suffisant pour le système d'exploitation, les processus NDB et le stockage dans les nœuds.

Même si nous faisons référence à Linux comme système d'exploitation dans ce guide, les instructions et les procédures sont faciles à adapter pour Solaris ou Mac OS X. Nous supposons aussi que vous savez faire une installation minimale et la configuration du système d'exploitation en réseau, ou que vous disposez d'assistance pour ce faire.

Nous allons présenter les besoins en matériel, logiciels et réseau pour le cluster MySQL dans la prochaine section. Voyez Section 16.3.1, « Matériel, logiciels et réseau »Matériel, logiciels et réseau.

16-3-1. Matériel, logiciels et réseau▲

Une des forces du Cluster MySQL est qu'il peut fonctionner sur n'importe quel serveur, et n'a pas de prérequis particulier, en dehors d'une grande quantité de mémoire vive, due au fait que toutes les données sont stockées en mémoire. Notez que cela pourrait changer à l'avenir, et que nous travaillons à avoir un stockage sur disque dans les prochaines versions du Cluster MySQL. Naturellement, les machines multiprocesseurs et celles aux fréquences supérieures seront plus rapides. Les besoins en RAM des processus du Cluster MySQL sont relativement raisonnables.

Les besoins en logiciels pour le Cluster MySQL sont aussi modestes. Les systèmes d'exploitation hôtes n'ont pas besoin de modules particuliers, ni services, ni applications ou configurations pour supporter Cluster MySQL. Pour Mac OS X ou Solaris, l'installation standard est suffisante. Pour Linux, une installation standard de base doit être suffisante. Les prérequis pour MySQL sont simples : tout ce qui est nécessaire pour faire fonctionner MySQL-max 4.1.3 ou plus récent ; vous devez utiliser la version -max de MySQL pour avoir le support du Cluster MySQL. Il n'est pas nécessaire de compiler MySQL vous-même pour être en mesure d'exécuter le Cluster MySQL. Dans cette documentation, nous allons supposer que vous utilisez le binaire -max adapté à votre système, disponible via la page de téléchargements de MySQL : http://dev.mysql.com/downloads.

Pour les communications entre les nœuds, Cluster MySQL supporte le protocole TCP/IP pour toutes les topologies, et le minimum attendu pour chaque hôte est une carte Ethernet 100 mégabits, plus un switch, hub ou routeur pour fournir la connectivité entre les parties du Cluster. Nous recommandons vivement que le Cluster MySQL dispose de son propre masque de sous-réseau pour les raisons suivantes.

Sécurité : les communications entre les nœuds du Cluster MySQL ne sont pas chiffrées ou protégées de quelque manière que ce soit. La seule solution pour protéger les transmissions à l'intérieur du Cluster MySQL est de placer le Cluster MySQL dans un réseau protégé. Si vous envisagez d'utiliser le Cluster MySQL pour une application Web, il est recommandé que le Cluster MySQL soit placé derrière un pare-feu, et non pas dans la zone démilitarisée (DMZ) ou ailleurs.
Efficacité : configurer un Cluster MySQL sur un réseau privé ou protégé donne au Cluster MySQL l'exclusivité de la bande passante. En utilisant un switch dédié au Cluster MySQL aide à la protection contre les accès non autorisés, et il protège les nœuds des interférences causées par les autres machines sur le réseau. Pour une stabilité accrue, vous pouvez utiliser des switchs redondants et des cartes réseau doubles pour supprimer du réseau les points de panne : de nombreux pilotes réseau savent s'adapter si une panne survient sur un brin de réseau.

Il est aussi possible d'utiliser l'interface SCI (Scalable Coherent Interface à haute vitesse, avec le Cluster MySQL, mais ce n'est pas nécessaire. Voyez Section 16.7, « Utilisation d'interconnexions haute vitesse avec MySQL Cluster »Utilisation d'interconnexions haute vitesse avec MySQL Cluster pour plus d'informations sur ce protocole et ses utilisations avec Cluster MySQL.

16-3-2. Installation▲

Chaque hôte du cluster MySQL qui héberge un nœud de stockage ou un nœud SQL doit être installé avec MySQL-max. Pour les nœuds de gestion, il n'est pas nécessaire d'installer un serveur MySQL, mais vous devez installer un démon MGM et les clients ndb_mgmd et ndb_mgm, respectivement. Dans cette section, nous allons voir les étapes nécessaires pour installer correctement chaque serveur pour un nœud du cluster.

Au moment de l'écriture de cette section, les versions les plus récentes étaient MySQL 4.1.10a ; si une version plus récente est disponible, il est recommandé de l'installer et d'utiliser ce numéro de version dans tout le reste de la section. MySQL fournit des serveurs précompilés, et il n'y a généralement pas besoin de compiler par vous-même. Si vous voulez faire une compilation personnalisée, voyez Section 2.4.3, « Installer à partir de l'arbre source de développement ». Par conséquent, la première étape de l'installation de chaque hôte du cluster est de télécharger le fichier mysql-max-4.1.10a-pc-linux-gnu-i686.tar.gz depuis MySQL downloads area. Nous supposons que vous l'avez fait, et installé dans le dossier /var/tmp de chaque machine.

Des RPM sont aussi disponibles pour les plateformes 32 et 62 bits; depuis MySQL 4.1.10a, les serveurs MySQL-max installés via RPM supportent les clusters NDB. Si vous choisissez d'utiliser ces outils plutôt que les fichiers binaires, assurez-vous d'installer à la fois les paquets -serveur et -max sur toutes les machines qui hébergent des nœuds du cluster. Voyez LinuxInstallation du logiciel pour plus d'informations sur l'installation de MySQL en RPM. Après l'installation des RPM, vous devez toujours configurer le cluster, tel que présenté dans Section 16.3.3, « Configuration »Configuration.

Note : après l'installation, ne lancez pas encore les logiciels. Nous allons vous montrer comment le faire, alors suivez d'abord la configuration des nœuds.

Installation des nœuds de stockage et SQL

Pour chacune des machines désignées pour être des hôtes de stockage ou des hôtes SQL, suivez les étapes suivantes, en tant que super utilisateur :

Vérifiez vos fichiers /etc/passwd et /etc/group ou utilisez les outils systèmes dont vous disposez pour gérer les groupes et utilisateurs pour vérifier si vous avez un groupe mysql et un utilisateur mysql sur votre système : certaines distributions les créent automatiquement lors de leur installation. Si ces comptes n'existent pas, alors créez un groupe mysql et un utilisateur mysql, comme ceci :
Sélectionnez
```
  groupadd mysql
  useradd -g mysql mysql
```
Placez-vous dans le dossier qui contient le fichier téléchargé; décompressez l'archive ; créez un lien symbolique vers l'exécutable mysql-max :
Sélectionnez
```
  cd /var/tmp
  tar -xzvf -C /usr/local/bin mysql-max-4.1.10a-pc-linux-gnu-i686.tar.gz
  ln -s /usr/local/bin/mysql-max-4.1.10a-pc-linux-gnu-i686 mysql
```
Placez-vous dans le dossier mysql, et exécutez le script fourni pour la création des bases de données système :
Sélectionnez
```
  cd mysql
  scripts/mysql_install_db --user=mysql
```
Donnez les droits nécessaires au serveur MySQL et au dossier de données :
Sélectionnez
```
  chown -R root .
  chown -R mysql data
  chgrp -R mysql .
```
Notez que le dossier de données de chaque machine qui héberge un nœud de stockage est /usr/local/mysql/data. Nous allons utiliser cette information lors de la configuration du nœud de gestion. Voyez Section 16.3.3, « Configuration »Configuration ;
Copiez le script de démarrage MySQL dans le dossier approprié, rendez-le exécutable, et configurez-le pour qu'il s'exécute lorsque le système d'exploitation démarre :

Sélectionnez

  cp support-files/mysql.server /etc/rc.d/init.d/
  chmod +x /etc/rc.d/init.d/mysql.server
  chkconfig --add mysql.server

Ici, nous utilisons la commande de Red Hat chkconfig pour créer les liens vers les scripts de démarrage ; utilisez les moyens appropriés pour faire la même chose sur votre système d'exploitation, tel que update-rc.d sur Debian.

N'oubliez pas que ces listes d'instructions doivent être exécutées séparément sur chaque machine qui sera un nœud de stockage ou un nœud SQL.

Installation du nœud de gestion

Pour le nœud MGM (serveur de gestion), il n'est pas nécessaire d'installer mysqld, mais seulement le serveur MGM et les clients, qui sont disponibles dans l'archive -max. Encore une fois, nous supposons que vous avez placé de fichier dans le dossier /var/tmp. En tant que root (c'est-à-dire, après avoir exécuté la commande su root ou l'équivalent sur votre système pour se faire attribuer les droits de super utilisateur), effectuez les commandes suivantes pour installer ndb_mgmd et ndb_mgm sur l'hôte de gestion :

Allez dans le dossier /var/tmp et décompressez ndb_mgm et ndb_mgmd de l'archive, dans un dossier approprié, comme /usr/local/bin :
Sélectionnez
```
  cd /var/tmp
  tar -zxvf mysql-max-4.1.10a-pc-linux-gnu-i686.tar.gz /usr/local/bin '*/bin/ndb_mgm*'
```
Placez-vous dans le dossier où vous avez décompressé les fichiers, puis rendez-les tous les deux exécutables :

Sélectionnez

  cd /usr/local/bin
  chmod +x ndb_mgm*

Dans Section 16.3.3, « Configuration »Configuration, nous allons créer et configurer les fichiers pour tous les nœuds du cluster d'exemple.

16-3-3. Configuration▲

Pour notre MySQL Cluster de quatre nœuds et quatre hôtes, nous aurons besoin de préparer quatre fichiers de configuration, un par hôte/nœud.

Chaque nœud de stockage ou nœud SQL a besoin d'un fichier my.cnf qui fournit deux informations : une chaîne connectstring qui indique au nœud où trouver le nœud MGM, et une ligne indiquant au serveur MySQL de cet hôte de fonctionner en mode NDB.
Pour plus d'informations sur les chaînes de connexion, voyez Section 16.4.4.2, « La chaîne connectstring du Cluster MySQL »La chaîne connectstring du Cluster MySQL.
Le nœud de gestion a besoin d'un fichier config.ini qui indique combien de répliques doivent être gérées, combien de mémoire allouer pour les données et les index sur chaque nœud de stockage, où trouver les nœuds de stockage, où les données seront sauvées sur le disque, et où trouver les nœuds SQL.

Configurer les nœuds de stockage et SQL

Le fichier my.cnf destiné aux nœuds de stockage est plutôt simple. Le fichier de configuration doit être placé dans le dossier /etc et peut être édité ou créé avec n'importe quel éditeur fichier. Par exemple :

Sélectionnez

vi /etc/my.cnf

Pour chaque nœud de stockage et chaque nœud SQL de notre exemple, le fichier my.cnf doit ressembler à ceci :

Sélectionnez

[MYSQLD]                        # Options du processus mysqld
ndbcluster                      # Fonctionne en mode NDB 
ndb-connectstring=192.168.0.10  # Situation du nœud MGM

[MYSQL_CLUSTER]                 # Options pour le processus ndbd
ndb-connectstring=192.168.0.10  # Situation du nœud MGM

Après la saisie des données ci-dessus, sauvez ce fichier et quittez l'éditeur de texte. Faites cela pour les nœuds de stockages « A » et « B », et le nœud SQL.

Configuration du nœud de gestion

La première étape de configuration du nœud MGM est la création du dossier dans lequel le fichier de configuration sera placé, et d'y créer le fichier lui-même. Par exemple, lors d'un fonctionnement root :

Sélectionnez

mkdir /var/lib/mysql-cluster
cd /var/lib/mysql-cluster
vi config.ini

Nous présentons ici la commande vi utilisée pour créer le fichier, mais n'importe quel autre éditeur texte fonctionne aussi bien.

Pour notre configuration d'exemple, config.ini doit contenir les informations suivantes.

Sélectionnez

[NDBD DEFAULT]    # Options affectant les processus ndbd processes sur tous les nœuds
NoOfReplicas=2    # Nombre de répliques
DataMemory=80M    # Mémoire à allouer pour le stockage des données
IndexMemory=52M   # Mémoire à allouer pour le stockage des index
                  # Pour DataMemory et IndexMemory, nous avons utilisé les 
                  # valeurs par défaut. Comme la base de données "world" 
                  # ne prend que 500KB, cela devrait être suffisant pour notre
                  # exemple de Cluster

[TCP DEFAULT]     # Options TCP/IP 
portnumber=2202   # Ceci est la valeur par défaut. Cependant, nous pourrions 
                  # utiliser un port libre pour les autres hôtes du cluster.
                  # Note : il est recommandé avec MySQL 5.0 de ne pas spécifier
                  # de port, et de laisser la valeur par défaut.

[NDB_MGMD]                      # Options de gestion des processus :
hostname=192.168.0.10           # Nom d'hôte ou adresse IP du nœud MGM
datadir=/var/lib/mysql-cluster  # Dossier des fichiers de logs du nœud MGM

[NDBD]                          # Options pour le stockage du nœud "A" :
                                # (une section [NDBD] par nœud de stockage)
hostname=192.168.0.30           # Nom d'hôte ou adresse IP
datadir=/usr/local/mysql/data   # Dossier pour les fichiers de données du nœud

[NDBD]                          # Options pour le stockage du nœud "B" :
hostname=192.168.0.40           # Nom d'hôte ou adresse IP
datadir=/usr/local/mysql/data   # Dossier pour les fichiers de données du nœud

[MYSQLD]                        # Options des nœuds SQL :
hostname=192.168.0.20           # Nom d'hôte ou adresse IP
datadir=/usr/local/mysql/data   # Dossier pour les fichiers SQL du nœud
                                # (Les connexions mysqld supplémentaires peuvent
                                # être spécifiées pour ce nœud pour différents
                                # objectifs, comme l'exécution de ndb_restore)

NOTE : la base de données « world » peut être téléchargée sur le site http://dev.mysql.com/doc/, rangé dans la section d'exemples : Examples.

Une fois que tous les fichiers de configuration ont été créés et que ces options minimales ont été spécifiées, vous êtes prêts à lancer le cluster MySQL et à vérifier que les processus fonctionnent. La présentation de cette étape est faite dans Section 16.3.4, « Démarrage initial »Démarrage initial.

Pour plus de détails sur les paramètres de configuration du cluster MySQL, voyez Section 16.4.4, « Fichier de configuration »Fichier de configuration et Section 16.4, « Configuration de MySQL Cluster »Configuration de MySQL Cluster. Pour la configuration du Cluster MySQL au sujet des sauvegardes, voyez Section 16.6.4.4, « Configuration pour la sauvegarde du Cluster »Configuration pour la sauvegarde du Cluster.

Note : le port par défaut pour le nœud de gestion du Cluster MySQL est le 1186, le port par défaut pour les nœuds de stockage est 2202.

16-3-4. Démarrage initial▲

Démarrer le cluster n'est pas très difficile une fois qu'il a été configuré. Chaque nœud doit être lancé séparément, et depuis l'hôte sur lequel il réside. Même s'il est possible de lancer les nœuds dans n'importe quel ordre, il est recommandé de lancer le serveur d'administration en premier, puis les nœuds de stockage et enfin, les nœuds SQL :

Sur l'hôte de gestion, utilisez la commande suivante depuis le Shell pour lancer le processus de gestion :
Sélectionnez
```
  shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini
```
Notez que ndb_mgmd doit recevoir le nom et chemin du fichier de configuration, avec l'option -f ou --config-file. Voyez Section 16.5.3, « ndb_mgmd, le serveur de gestion »ndb_mgmd, le serveur de gestion pour plus de détails ;
Sur chaque hôte de stockage, exécutez cette commande pour lancer les processus NDBD :
Sélectionnez
```
  shell> ndbd --initial
```
Notez qu'il est très important d'utiliser le paramètre --initial uniquement lors du premier démarrage de ndbd, ou lors du redémarrage après une opération de restauration des données ou de modification de configuration. En effet, ce paramètre va forcer le nœud à effacer les fichiers créés par les anciennes instances de ndbd, y compris les fichiers de log ;
Sur les hôtes SQL, exécutez une commande mysqld classique :

Sélectionnez

  shell> mysqld &

Si tout se passe bien, et que le cluster a été correctement configuré, il devrait être opérationnel à nouveau. Vous pouvez tester cela en utilisant la commande ndb_mgm, c'est-à-dire le client de gestion ; le résultat devrait être similaire à celui-ci :

Sélectionnez

shell> ndb_mgm
-- NDB Cluster -- Management Client --
ndb_mgm> show
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=2    @192.168.0.30  (Version: 4.1.11, Nodegroup: 0, Master)
id=3    @192.168.0.40  (Version: 4.1.11, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)
id=1    @192.168.0.10  (Version: 4.1.11)

[mysqld(SQL)]   1 node(s)
id=4   (Version: 4.1.11)

Vous pouvez rencontrer diverses adaptations en fonction des versions exactes de MySQL que vous utilisez.

Note : si vous utilisez une ancienne version de MySQL, vous pourriez voir les nœuds SQL référencés sous le nom '[mysqld(API)]'. C'est une ancienne pratique qui n'a plus cours.

Vous êtes maintenant prêts à utiliser vos bases de données, vos tables et vos données dans le cluster MySQL. Voyez Section 16.3.5, « Charger les données d'exemple et exécuter des requêtes »Charger les données d'exemple et exécuter des requêtes pour aller plus loin.

16-3-5. Charger les données d'exemple et exécuter des requêtes▲

Travailler avec le cluster MySQL n'est pas différent de travailler avec un serveur MySQL classique. Il y a deux points importants à garder en tête.

Les tables doivent être créées avec le moteur ENGINE=NDB ou ENGINE=NDBCLUSTER, ou doivent être modifiées avec ALTER TABLE pour qu'elles utilisent le moteur NDB, afin qu'elles soient gérées par le cluster. Si vous importez des tables depuis une base de données existante en utilisant le résultat de mysqldump, vous pouvez ouvrir le script SQL dans un éditeur de texte, et ajoutez cette option à toutes les créations de tables, ou bien remplacez les options ENGINE ou TYPE) avec l'une des valeurs ci-dessous. Par exemple, en supposant que vous utilisez la base world dans un autre serveur MySQL, qui ne supporte pas le cluster MySQL, et que vous voulez exporter la définition de la table CITY :
Sélectionnez
```
  shell> mysqldump --add-drop-table world City > city_table.sql
```
Le résultat du fichier city_table.sql contient la commande de création de la table et les commandes d'insertion INSERT pour importer les données dans la table :
Sélectionnez
```
  DROP TABLE IF EXISTS City;
  CREATE TABLE City (
      ID int(11) NOT NULL auto_increment,
      Name char(35) NOT NULL default '',
      CountryCode char(3) NOT NULL default '',
      District char(20) NOT NULL default '',
      Population int(11) NOT NULL default '0',
      PRIMARY KEY  (ID)
  ) TYPE=MyISAM;

  INSERT INTO City VALUES (1,'Kabul','AFG','Kabol',1780000);
  INSERT INTO City VALUES (2,'Qandahar','AFG','Qandahar',237500);
  INSERT INTO City VALUES (3,'Herat','AFG','Herat',186800);
  # (remaining INSERT statements omitted)
```
Vous devez vous assurer que MySQL utilise le moteur NBD pour cette table. Il y a deux moyens pour le faire. L'un d'eux, avant l'importation des données dans la table, consiste à modifier la définition de la table pour qu'elle corresponde à ceci (toujours en utilisant la table City) :
Sélectionnez
```
  DROP TABLE IF EXISTS City;
  CREATE TABLE City (
      ID int(11) NOT NULL auto_increment,
      Name char(35) NOT NULL default '',
      CountryCode char(3) NOT NULL default '',
      District char(20) NOT NULL default '',
      Population int(11) NOT NULL default '0',
      PRIMARY KEY  (ID)
  ) ENGINE=NDBCLUSTER;

  INSERT INTO City VALUES (1,'Kabul','AFG','Kabol',1780000);
  INSERT INTO City VALUES (2,'Qandahar','AFG','Qandahar',237500);
  INSERT INTO City VALUES (3,'Herat','AFG','Herat',186800);
  # (etc.)
```
Cela doit être fait pour la définition de chaque table qui fait partie de la base de données en cluster. Le plus simple pour faire cela est de faire un rechercher/remplacer dans le fichier world.sql et de remplacer toutes les instances de TYPE=MyISAM par ENGINE=NDBCLUSTER. Si vous ne voulez pas modifier ce fichier, vous pouvez aussi utiliser la commande ALTER TABLE; voyez plus bas pour les spécificités.

En supposant que vous avez déjà créé la base de données appelée world sur le nœud SQL du cluster, vous pouvez utiliser l'utilitaire de ligne de commande mysql pour lire le fichier city_table.sql, et créer puis remplir la table, comme ceci :
Sélectionnez
```
  shell> mysql world < city_table.sql
```
Il est très important de garder en tête que les commandes ci-dessus doivent être exécutées sur l'hôte où le nœud SQL tourne : dans ce cas, sur la machine avec l'adresse IP 192.168.0.20.

Pour créer une copie de la base de données world sur le nœud SQL, sauvez le fichier dans /usr/local/mysql/data, puis exécutez ces commandes :
Sélectionnez
```
  shell> cd /usr/local/mysql/data
  shell> mysql world < world.sql
```
Bien sûr, le script SQL doit être lisible par l'utilisateur mysql. Si vous sauvez le fichier à un autre endroit, ajustez les chemins dans les commandes ci-dessus.

Exécuter les commandes SELECT sur un nœud SQL n'est pas différent de les exécuter sur une autre instance de serveur MySQL. Pour exécuter les requêtes SQL en ligne de commande, vous devez vous identifier sur le serveur, comme d'habitude :
Sélectionnez
```
  shell> mysql -u root -p
  Enter password:
  Welcome to the MySQL monitor.  Commands end with ; or \g.
  Your MySQL connection id is 1 to server version: 4.1.9-max

  Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

  mysql>
```
Si vous n'avez pas modifié les clauses ENGINE= dans les définitions de tables, vous pouvez alors utiliser ces commandes :
Sélectionnez
```
  mysql> USE world;
  mysql> ALTER TABLE City ENGINE=NDBCLUSTER;
  mysql> ALTER TABLE Country ENGINE=NDBCLUSTER;
  mysql> ALTER TABLE CountryLanguage ENGINE=NDBCLUSTER;
```
Notez que nous avons simplement utilisé le compte d'administrateur par défaut, sans mot de passe. Bien entendu, dans un environnement de production, il est recommandé de toujours suivre les précautions de sécurité, y compris l'utilisation d'un mot de passe robuste pour le super utilisateur, et la création d'un compte spécifique, avec uniquement les droits nécessaires aux tâches incombantes. Pour plus de détails, voyez la section Section 5.5, « Règles de sécurité et droits d'accès au serveur MySQL ».

Il est à noter que les nœuds du cluster n'utilisent pas les droits d'accès MySQL lorsqu'ils se connectent l'un à l'autre : modifier ces droits n'a pas d'effet sur les communications entre les nœuds.

Sélectionner la base de données et exécuter une requête SELECT sur une table se fait comme d'habitude :
Sélectionnez
```
  mysql> USE world;
  mysql> SELECT Name, Population FROM City ORDER BY Population DESC LIMIT 5;
  +-----------+------------+
  | Name      | Population |
  +-----------+------------+
  | Bombay    |   10500000 |
  | Seoul     |    9981619 |
  | SÃ£o Paulo |    9968485 |
  | Shanghai  |    9696300 |
  | Jakarta   |    9604900 |
  +-----------+------------+
  5 rows in set (0.34 sec)

  mysql> \q
  Bye

  shell>
```
Les applications qui reposent sur MySQL peuvent utiliser l'API standard. Il est important de penser à ce que votre application doit se connecter à un nœud SQL, et non pas aux nœuds de stockage ou au serveur de gestion. Cet exemple montre comment vous pourriez exécuter une requête en utilisant l'extension mysqli de PHP 5, sur un serveur Web :
Sélectionnez
```
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
  <html>
  <head>
    <meta http-equiv="Content-Type"
          content="text/html; charset=iso-8859-1">
    <title>Sélection de données avec mysqli</title>
  </head>
  <body>
  <?php
    # Connexion au nœud SQL :
    $link = new mysqli('192.168.0.20', 'root', '', 'world');
    # Les paramètres pour le constructeur mysqli sont :
    #   hote, utilisateur, mot de passe, base de données
    
    if( mysqli_connect_errno() ) {
      die("Connexion échouée : " . mysqli_connect_error());
    }
    
    $query = "SELECT Name, Population
              FROM City
              ORDER BY Population DESC
              LIMIT 5";

    # s'il n'y a pas d'erreur
    if( $result = $link->query($query) )
     {
  ?>
  <table border="1" width="40%" cellpadding="4" cellspacing ="1">
    <tbody>
    <tr>
      <th width="10%">Ville</th>
      <th>Population</th>
    </tr>
  <?php
      // Affichage du résultat
      while($row = $result->fetch_object())
        printf(<tr>\n  <td align=\"center\">%s</td><td>%d</td>\n</tr>\n",
                $row->Name, $row->Population);
  ?>
    </tbody
  </table>
  <?php
   // Vérification du nombre de lignes lues
      printf("<p>Lignes affectées : %d</p>\n", $link->affected_rows);
    }
    else
      # Sinon, affichage de l'erreur
      echo mysqli_error();

    // Libération du résultat et de l'objet de connexion
    $result->close();
    $link->close();
  ?>
  </body>
  </html>
```
Nous supposons que le processus du serveur Web peut atteindre l'IP du nœud SQL.

De manière similaire, vous pouvez utiliser l'API C de MySQL, ou les interfaces Perl-DBI, Python-mysql ou encore les connecteurs de MySQL AB pour effectuer les tâches de définition de données et de manipulations, comme vous le faites habituellement avec un serveur MySQL.
N'oubliez pas que toutes les tables NDB doivent avoir une clé primaire. Si aucune clé primaire n'est définie par l'utilisateur lors de la création de la table, le moteur de stockage NDB va en générer une automatiquement. Note : cette clé cachée prend de l'espace, comme tout autre index. Il n'est pas rare de rencontrer des problèmes de mémoire lorsque vous devez prendre en compte ces clés automatiques.

16-3-6. Arrêt et redémarrage du cluster▲

Pour arrêter le cluster, utilisez simplement cette commande dans le Shell sur la machine qui héberge le serveur de gestion MGM :

Sélectionnez

shell> ndb_mgm -e shutdown

Cela va forcer les processus ndb_mgm, ndb_mgm et ndbd à s'arrêter proprement. Tous les nœuds SQL peuvent alors être arrêtés avec la commande mysqladmin shutdown classique ou par d'autres moyens.

Pour relancer le cluster, lancez simplement ces commandes :

sur l'hôte de gestion (192.168.0.10 dans notre cas) :
Sélectionnez
```
  shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini
```
sur chaque nœud de stockage (192.168.0.30 et 192.168.0.40) :
Sélectionnez
```
  shell> ndbd
```
N'oubliez pas d'invoquer cette commande avec l'option --initial lorsque vous redémarrez un nœud NDBD normalement.
Et les hôtes SQL (192.168.0.20) :

Sélectionnez

  shell> mysqld &

Pour des informations sur les sauvegardes, voyez Section 16.6.4.2, « Utilisation du serveur de gestion pour une sauvegarde de cluster »Utilisation du serveur de gestion pour une sauvegarde de cluster.

Pour restaurer le cluster à partir de sauvegardes, il faut utiliser la commande ndb_restore. Vous pouvez vous informer là-dessus sur Section 16.6.4.3, « Comment restaurer une sauvegarde du cluster »Comment restaurer une sauvegarde du cluster.

Plus d'informations sur la configuration du cluster MySQL sont disponibles dans Section 16.4, « Configuration de MySQL Cluster »Configuration de MySQL Cluster.

Un serveur MySQL est une partie d'un cluster MySQL, et il ne diffère d'un serveur classique que d'un seul aspect : il dispose d'un moteur de stockage supplémentaire, à savoir : NDB ou NDBCLUSTER.

À part cela, le serveur MySQL n'est pas très différent de ceux que nous utilisons traditionnellement. Par défaut, le serveur est configuré sans le moteur NDB (pour éviter d'allouer des ressources inutiles). Pour activer NDB, vous devez modifier my.cnf.

De plus, comme le serveur MySQL est une partie du cluster, il doit savoir comment accéder au nœud MGM, pour connaître la configuration du cluster. Il y a un comportement par défaut qui recherche le nœud MGM sur le serveur local. Mais si vous devez le placer ailleurs, vous pouvez le taper en ligne de commande ou bien dans le fichier my.cnf. Avant que le moteur de stockage NDB ne soit utilisé, un nœud MGM est une base de nœud qui doit être active et accessible. Le seul nœud MGM est suffisant pour démarrer.

16-4-1. Compilation du cluster▲

NDB Cluster est disponible en distribution binaire depuis MySQL-Max 4.1.3.

Si vous décidez de compiler le cluster depuis les sources ou depuis MySQL 4.1 BitKeeper, assurez-vous d'utiliser l'option --with-ndbcluster avec la commande configure.

Vous pouvez aussi utiliser simplement le script BUILD/compile-pentium-max. Ce script inclut aussi OpenSSL, ce qui vous impose d'avoir OpenSSL installé ou de modifier le script de compilation pour l'exclure.

À part cela, vous pouvez suivre les instructions standard de compilation pour créer vos propres programmes, effectuer les tests et l'installation. Voir Section 2.4.3, « Installer à partir de l'arbre source de développement ».

16-4-2. Installation du logiciel▲

Il est plus facile de faire l'installation si vous avez déjà installé les serveurs de gestion (MGM) et les nœuds de bases (DB), et qu'ils sont actifs : cela sera sûrement la partie la plus longue de l'installation, en supposant que vous êtes déjà maitre de MySQL. Comme pour les fichiers de configuration et my.cnf, la structure du fichier est très claire, et cette section ne couvre que les différences spécifiques du cluster, par rapport à MySQL classique.

16-4-3. Vérification rapide du fonctionnement du cluster▲

Cette section montre comment configurer rapidement puis démarrer l'architecture la plus simple d'un cluster MySQL. Vous serez alors familiers avec les concepts de base. Puis, lisez les autres sections pour adapter plus finement votre installation.

Un dossier doit être créé. L'exemple utilise /var/lib/mysql-cluster. Exécutez la commande suivante, en tant que root :

Sélectionnez

shell> mkdir /var/lib/mysql-cluster

Dans ce dossier, créez un fichier config.ini avec le contenu suivant. Remplacez HostName et DataDir par les valeurs de votre installation.

Sélectionnez

# file "config.ini" - showing minimal setup consisting of 1 DB node,
# 1 management server, and 3 MySQL servers.
# The empty default sections are not needed, and are shown only for clarity.
# Storage nodes are required to provide a host name but MySQL Servers
# are not. Thus the configuration can be dynamic as to setting up the
# MySQL Servers.
# If you don't know the host name of your machine, use localhost.
# The DataDir parameter also has a default value, but it is recommended to
# set it explicitly.
# NDBD, MYSQLD, and NDB_MGMD are aliases for DB, API, and MGM respectively
#
[NDBD DEFAULT]
NoOfReplicas= 1

[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[TCP DEFAULT]

[NDB_MGMD]
HostName= myhost.example.com 

[NDBD]
HostName= myhost.example.com 
DataDir= /var/lib/mysql-cluster

[MYSQLD]
[MYSQLD]
[MYSQLD]

Vous pouvez maintenant lancer le serveur de gestion. Pour cela, faites :

Sélectionnez

shell> cd /var/lib/mysql-cluster
shell> ndb_mgmd

Puis, lancez un nœud de base, grâce au programme ndbd. Si c'est la toute première fois que vous lancez ndbd, utilisez l'option --initial :

Sélectionnez

shell> ndbd --initial

Lors des prochains appels à ndbd, ne l'utilisez plus.

Sélectionnez

shell> ndbd

Par défaut, ndbd va rechercher le serveur de gestion sur localhost, port 2200.

Notez que si vous avez installé une distribution binaire, vous aurez besoin de spécifier explicitement le chemin des commandes ndb_mgmd et ndbd. Ils se trouvent dans le dossier /usr/local/mysql/bin.

Finalement, allez dans le dossier de données MySQL (il sera probablement dans /var/lib/mysql ou /usr/local/mysql/data). Assurez-vous que le fichier my.cnf contient les options nécessaires pour activer le moteur NDB Cluster :

Sélectionnez

[mysqld]
ndbcluster

Vous pouvez maintenant lancer le serveur MySQL comme d'habitude :

Sélectionnez

shell> mysqld_safe --user=mysql &

Attendez un moment, et assurez-vous que le serveur fonctionne correctement. Si vous voyez un message « mysql ended », vérifiez le fichier d'erreur du serveur .err pour savoir ce qui se passe.

Si tout est bien allé, vous pouvez lancer le cluster :

Sélectionnez

shell> mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.7-gamma

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> SHOW STORAGE ENGINES;
+------------+---------+------------------------------------------------------------+
| Engine     | Support | Comment                                                    |
+------------+---------+------------------------------------------------------------+
...
| NDBCLUSTER | DEFAULT | Clustered, fault-tolerant, memory-based tables             |
| NDB        | YES     | Alias for NDBCLUSTER                                       |
...

mysql> USE test;
Database changed

mysql> CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (0.09 sec)

mysql> show create table ctest \G
*************************** 1. row ***************************
       Table: ctest
Create Table: CREATE TABLE `ctest` (
  `i` int(11) default NULL
) ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

Si vous voulez vérifier que vos nœuds ont été correctement configurés, vous pouvez lancer le client de gestion :

Sélectionnez

shell> ndb_mgm

Essayez d'utiliser la commande SHOW pour avoir un aperçu du cluster :

Sélectionnez

NDB> show
Cluster Configuration
---------------------
[ndbd(NDB)]     1 node(s)
id=2    @127.0.0.1  (Version: 3.5.3, Nodegroup: 0, Master)

[ndb_mgmd(MGM)] 1 node(s)
id=1    @127.0.0.1  (Version: 3.5.3)

[mysqld(API)]   3 node(s)
id=3    @127.0.0.1  (Version: 3.5.3)
id=4 (not connected, accepting connect from any host)
id=5 (not connected, accepting connect from any host)

Le cluster est à vous !

16-4-4. Fichier de configuration▲

La configuration d'un cluster MySQL est placée dans un fichier de configuration. Ce fichier est lu par le serveur de gestion, puis distribué à tous les processus qui sont impliqués dans le cluster. Ce fichier contient la description de toutes machines impliquées dans le cluster, les paramètres de configuration pour les nœuds de stockage et les paramètres de configuration entre les nœuds.

16-4-4-1. Exemple de configuration d'un cluster MySQL▲

Actuellement, le fichier de configuration est au format INI, et il s'appelle config.ini par défaut. Il est placé dans le dossier de démarrage de ndb_mgmd, le serveur de gestion.

Les options préconfigurées sont disponibles pour la plupart des paramètres, et les valeurs par défaut peuvent être définies dans le fichier config.ini. Pour créer une section de valeurs par défaut, ajoutez le mot DEFAULT au nom de la section. Par exemple, les nœuds DB sont configurés avec la section [DB]. Si tous les nœuds DB utilisent la même quantité de mémoire, et que cette valeur n'est pas la valeur par défaut, alors créez une section [DB DEFAULT] qui contient le paramètre DataMemory, et qui spécifiera la valeur par défaut de la taille de mémoire des nœuds DB.

Le format INI est constitué de sections, précédées par des entêtes de sections (entourées de crochets), suivis de paramètres et leur valeur. Un changement par rapport au format standard est que le paramètre et sa valeur peuvent être séparés par un deux-points ':' en plus du signe égal '=', et un autre est que les sections ne sont pas uniques. Au lieu de cela, les entrées uniques comme deux nœuds du même type sont identifiées par un ID distinct.

Un fichier de configuration minimal doit définir les ordinateurs du cluster, et les nœuds impliqués, ainsi que les ordinateurs sur lesquels ces nœuds sont installés.

Un exemple de fichier de configuration minimal pour un cluster avec un serveur de gestion, deux serveurs de stockage et deux serveurs MySQL est présenté ci-dessous :

Sélectionnez

# file "config.ini" - 2 DB nodes and 2 mysqld
# This file is placed in the start directory of ndb_mgmd,
# the management server.
# The first MySQL Server can be started from any host and the second
# can only be started at the host mysqld_5.mysql.com
# NDBD, MYSQLD, and NDB_MGMD are aliases for DB, API, and MGM respectively
#
[NDBD DEFAULT]
NoOfReplicas= 2
DataDir= /var/lib/mysql-cluster

[NDB_MGMD]
Hostname= ndb_mgmd.mysql.com
DataDir= /var/lib/mysql-cluster

[NDBD]
HostName= ndbd_2.mysql.com

[NDBD]
HostName= ndbd_3.mysql.com

[MYSQLD]
[MYSQLD]
HostName= mysqld_5.mysql.com

Il y a ici six sections dans le fichier. [COMPUTER] définit les ordinateurs du cluster. [API|MYSQLD] définit les nœuds de serveur MySQL du cluster. [MGM|NDB_MGMD] définit le serveur de gestion du cluster. [TCP] définit les connexions TCP/IP entre les nœuds du cluster, TCP/IP est le mécanisme de connexion par défaut entre deux nœuds. [SHM] définit les connexions par mémoire partagée entre les nœuds. Ce n'est possible que si les nœuds ont été compilés avec l'option --with-ndb-shm.

Pour chaque section, il est possible de définir un comportement par défaut, DEFAULT. Les paramètres sont insensibles à la casse depuis MySQL 4.1.5.

16-4-4-2. La chaîne connectstring du Cluster MySQL▲

À l'exception du serveur de gestion du cluster MySQL (ndb_mgmd), chaque nœud du cluster MySQL a besoin d'une chaîne connectstring qui pointe sur le serveur de gestion. Elle sert à établir la connexion avec le serveur de gestion, ainsi qu'à réaliser d'autres tâches en fonction du rôle du nœud dans le cluster. La syntaxe pour la chaîne connectstring est la suivante :

Sélectionnez

<connectstring> :=
[<nodeid-specification>,]<host-specification>[,<host-specification>]
<nodeid-specification> := nodeid=<id>
<host-specification> := <host>[:<port>]

<id> est un entier plus grand que 1 qui identifie un nœud dans le fichier config.ini. <port> est un entier qui représente le port Unix. <host> est une chaîne qui est une adresse valide d'hôte Internet.

Sélectionnez

example 1 (long):    "nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
example 2 (short):   "myhost1"

Tous les nœuds vont utiliser localhost:1186 comme chaîne par défaut, si elle n'est pas spécifiée. Si <port> est omis dans la chaîne, le port par défaut est 1186. (Note : avant MySQL 4.1.8, le port par défaut était 2200.) Ce port doit toujours être disponible sur le réseau, car il a été assigné par l'IANA pour cela (voyez http://www.iana.org/assignments/port-numbers pour les détails).

En listant plusieurs valeurs <host-specification>, il est possible de désigner plusieurs serveurs de gestion redondants. Un nœud de cluster va tenter de contacter successivement chaque serveur, dans l'ordre spécifié, jusqu'à ce qu'une connexion soit établie.

Il y existe plusieurs moyens de spécifier la chaîne connectstring :

chaque programme a sa propre option de ligne de commande qui permet de spécifier le serveur de gestion au démarrage. Voyez la documentation respective de chaque programme ;
depuis MySQL 4.1.8, il est aussi possible de configurer connectstring pour chaque nœud du cluster en plaçant une section [mysql_cluster] dans le fichier de configuration du serveur de gestion my.cnf ;
pour la compatibilité ascendante, deux autres options sont disponibles en utilisant la même syntaxe :
1. Configurer la variable d'environnement NDB_CONNECTSTRING pour qu'elle contienne connectstring,
2. Placez la chaîne connectstring pour chaque programme dans un fichier texte appelé Ndb.cfg et placez de fichier dans le dossier de démarrage.

La méthode recommandée pour spécifier la chaîne connectstring est de passer par la ligne de commande ou par le fichier my.cnf.

16-4-4-3. Définition des ordinateurs dans un cluster MySQL▲

La section [COMPUTER] n'a pas d'autre signification que de système de noms pour les nœuds du système. Tous les paramètres cités ici sont obligatoires.

[COMPUTER]Id
C'est l'identité interne dans le fichier de configuration. Ultérieurement, on appellera cette entité un identifiant. C'est un entier.
[COMPUTER]HostName
Ceci est le nom d'hôte de l'ordinateur. Il est possible d'utiliser une adresse IP plutôt que son nom d'hôte.

16-4-4-4. Définition du serveur de gestion du cluster▲

La section [MGM] (et son alias [NDB_MGMD]) sert à configurer le comportement du serveur de gestion. Le paramètre obligatoire est soit ExecuteOnComputer, soit HostName. Tous les autres paramètres peuvent être omis, et ils prendront leur valeur par défaut.

[MGM]Id
C'est l'identité du nœud, utilisée comme adresse dans les messages internes. C'est un entier compris entre 1 et 63. Chaque nœud du cluster a une identité unique.
[MGM]ExecuteOnComputer
Fait référence à un des ordinateurs définis dans la section COMPUTEUR.
[MGM]PortNumber
C'est le numéro de port que le serveur de gestion utilisera pour attendre les demandes de configuration et les commandes de gestion.
[MGM]LogDestination
Ce paramètre spécifie la destination du log du cluster. Il y a plusieurs destinations possibles, et elles peuvent être utilisées en parallèle. Les valeurs possibles sont CONSOLE, SYSLOG et FILE. Pour les configurer, il faut les mettre sur une même ligne, séparés par des points-virgules ';'.
CONSOLE envoie sur la sortie standard, et aucun autre paramètre n'est nécessaire.
Sélectionnez
```
CONSOLE
```
SYSLOG correspond à l'envoi log système. Il est nécessaire d'indiquer une méthode ici. Les méthodes possibles sont : auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. Notez que toutes ces options ne sont pas forcément supportées par tous les systèmes d'exploitation.
Sélectionnez
```
SYSLOG:facility=syslog
```
FILE représente un fichier standard sur la machine. Il est nécessaire de spécifier un nom de fichier, la taille maximale du fichier avant l'ouverture d'un nouveau fichier. L'ancien sera alors renommé avec l'extension .x où x est le prochain nombre libre. Il est aussi nécessaire de spécifier le nombre maximal de fichiers utilisés.
Sélectionnez
```
FILE:filename=cluster.log,maxsize=1000000,maxfiles=6
```
Il est possible de spécifier plusieurs destinations de logs comme ceci :
Sélectionnez
```
CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd
```
La valeur par défaut de ce paramètre est FILE:filename=cluster.log,maxsize=1000000,maxfiles=6.
[MGM]ArbitrationRank
Ce paramètre est utilisé pour définir les nœuds qui servent d'arbitre. Les nœuds de gestion MGM et les nœuds API peuvent être utilisés comme arbitre. 0 signifie que le nœud n'est pas utilisé comme arbitre, 1 est la priorité haute, et 2 la priorité basse. Une configuration normale utilise les serveurs de gestion comme arbitre avec ArbitrationRank à 1 (c'est la valeur par défaut) et les nœuds d'API à 0 (ce n'est pas le défaut en MySQL 4.1.3).
[MGM]ArbitrationDelay
Si vous donnez une valeur différente de 0 à cette option, cela signifie que le serveur de gestion retarde ses réponses d'autant, lorsqu'il reçoit des demandes d'arbitrage. Par défaut, il n'y a pas de délai, et c'est très bien comme ça.
[MGM]DataDir
C'est le dossier où les fichiers de résultats du serveur de gestion seront placés. Ces fichiers sont les fichiers de logs, les affichages de processus et le PID pour le démon.

16-4-4-5. Définitions des nœuds de stockage dans un cluster MySQL▲

La section [DB] et son alias [NDBD] servent à configurer le comportement des nœuds de stockage. Il y a de nombreux paramètres spécifiés qui contrôlent les tailles de buffer, les tailles de files ou les délais d'expiration, etc. Le seul paramètre obligatoire est soit ExecuteOnComputer ou HostName et le paramètre NoOfReplicas qui doit être défini dans la section [DB DEFAULT]. La plupart des paramètres doivent être dans la section [DB DEFAULT]. Seuls les paramètres explicitement présentés comme ayant une valeur locale peuvent être modifiés dans la section [DB]. HostName, Id et ExecuteOnComputer doivent être définies dans la section [DB].

La valeur de Id, ou l'identité d'un nœud de stockage peut être allouée au démarrage du nœud. Il est toujours possible d'assigner un identifiant dans un fichier de configuration.

Pour chaque paramètre, il est possible d'utiliser les suffixes k, M ou G, pour indiquer des multiples 1024, (1024*1024) et (1024* 1024*1024) de l'unité. Par exemple, 100 k représente 102 400. Les paramètres et leur valeur sont actuellement sensibles à la casse.

[DB]Id
Cet identifiant est l'identité du nœud, utilisé pour référencer le nœud dans le cluster. C'est un entier compris entre 1 et 63. Chaque nœud du cluster doit avoir une identité distincte.
[DB]ExecuteOnComputer
Cela fait référence à un des ordinateurs définis dans la section 'Computer'.
[DB]HostName
Ce paramètre revient à spécifier un ordinateur sur lequel placer l'exécution. Il définit un nom d'hôte sur lequel réside le nœud de stockage. Ce paramètre ou ExecuteOnComputer est obligatoire.
[DB]ServerPort
Chaque nœud dans le cluster utilise un port pour se connecter avec les autres nœuds du cluster. Ce port est aussi utilisé pour les connexions lors de la phase de mise en place. Ce port par défaut sera utilisé pour s'assurer qu'aucun nœud sur le même ordinateur ne reçoit le même numéro de port. Le numéro de port minimum est 2202.
[DB]NoOfReplicas
Ce paramètre ne peut être configuré que dans la section [DB DEFAULT], car c'est un paramètre global. Il définit le nombre de répliques de chaque table stockée dans le cluster. Ce paramètre spécifie aussi la taille du groupe de nœuds. Un groupe de nœuds est un ensemble de nœuds qui stockent les mêmes informations.
Les groupes de nœuds sont formés implicitement. Le premier groupe est formé par les nœuds de stockage avec les identités les plus petites, puis par ordre d'identité croissante. Par exemple, supposons que nous avons quatre nœuds de stockage et que NoOfReplicas vaut 2. Les quatre nœuds de stockage ont les identifiants 2, 3, 4 et 5. Le premier groupe de nœuds sera formé par les nœuds 2 et 3, et le second groupe sera formé de 4 et 5. Il est important de configurer le cluster pour que les nœuds d'un même groupe ne soient pas placés sur le même ordinateur. Sinon, cela pourrait conduire à avoir un point de faiblesse : un seul ordinateur peut planter le cluster.
Si aucune identité n'est spécifiée, alors l'ordre des nœuds de stockage va être le facteur déterminant du groupe de nœuds. Le groupe de nœuds ainsi généré peut être affiché avec la commande SHOW dans le client de gestion.
Il n'y a pas de valeur par défaut, et la valeur maximale est 4.
[DB]DataDir
Ce paramètre spécifie le dossier où les fichiers de traces, les fichiers de logs, et les fichiers d'erreurs sont rangés.
[DB]FileSystemPath
Ce paramètre spécifie le dossier où tous les fichiers créés pour stocker les métadonnées, les logs de REDO, les logs de UNDO et les fichiers de données sont rangés. La valeur par défaut est DataDir. Le dossier doit être créé avant de lancer le processus ndbd.
Si vous utilisez la hiérarchie de dossiers recommandée, vous utiliserez le dossier /var/lib/mysql-cluster. Sous ce dossier, un autre dossier ndb_2_fs sera créé (si l'identifiant de nœud est 2), pour servir de fichier système pour le nœud.
[DB]BackupDataDir
Il est possible de spécifier le dossier où les sauvegardes seront placées. Par défaut, le dossier FileSystemPath/BACKUP sera utilisé.

DataMemory et IndexMemory sont les paramètres qui spécifient la taille des segments de mémoire utilisés pour stocker les lignes et leur index. Il est important de comprendre comment DataMemory et IndexMemory sont utilisés pour comprendre comment choisir ces paramètres. Pour la majorité des cas, ils doivent être mis à jour pour refléter leur utilisation dans le cluster.

[DB]DataMemory
Ce paramètre est l'un des paramètres les plus importants, car il définit l'espace disponible pour stocker les lignes dans la base de données. Tout l'espace DataMemory sera alloué en mémoire : il est donc important que la machine contienne assez de mémoire pour stocker DataMemory.
DataMemory sert à stocker deux choses. Il stocke les lignes de données. Chaque ligne est de taille fixe. Les colonnes VARCHAR sont stockées sous forme de colonnes à taille fixe. De plus, chaque enregistrement est stocké dans une page de 32 ko avec 128 octets d'entête. Il y a donc un peu de pertes pour chaque page, car chaque ligne n'est stockée que sur une seule page. La taille maximale d'une colonne est actuellement de 8052 octets.
DataMemory sert aussi à stocker les index ordonnés. Les index ordonnés prennent environ 10 octets par ligne. Chaque ligne dans une table est représentée par un index ordonné.
DataMemory est constitué de pages de 32 ko. Ces pages sont allouées comme partitions pour les tables. Chaque table est généralement répartie en autant de partitions qu'il y a de nœuds dans le cluster. Par conséquent, il y a le même nombre de partitions (fragments) que la valeur de NoOfReplicas. Une fois qu'une page a été allouée, il n'est pas possible actuellement de la libérer. La méthode pour récupérer cet espace est d'effacer la table. Effectuer une restauration de nœuds va aussi compresser la partition, car toutes les lignes seront insérées dans une partition vide, depuis un autre nœud.
Un autre aspect important est que DataMemory contient aussi les informations de UNDO (annulation) pour chaque ligne. Pour chaque modification d'une ligne, une copie de la ligne est faite dans l'espace DataMemory. De plus, chaque copie va aussi avoir une instance dans l'index ordonné. Les index Hash unique sont modifiés uniquement lorsque les colonnes uniques sont modifiées dans ce cas, une nouvelle entrée est insérée dans la table. Au moment de l'archivage (commit), l'ancienne valeur est effacée. Il est donc nécessaire de pouvoir allouer la mémoire nécessaire pour gérer les plus grosses transactions effectuées dans le cluster.
Effectuer une transaction de grande taille n'a pas d'autre intérêt avec le Cluster MySQL que la cohérence, ce qui est la base des transactions. Les transactions ne sont pas plus rapides, et consomment beaucoup de mémoire.
La taille par défaut de DataMemory est 80 MB. La taille minimum est de 1 MB. Il n'y a pas de taille maximum, mais en réalité, il faut adapter la valeur pour éviter que le système n'utilise la mémoire sur le disque, par ce que la mémoire physique a été dépassée.
[DB]IndexMemory
IndexMemory est le paramètre qui contrôle la quantité d'espace utilisée pour les index hash de MySQL Cluster. Les index hash sont toujours utilisés pour les clés primaires, les index uniques et les contraintes d'unicité. En fait, lors de la définition d'une clé primaire et d'une clé unique, deux index distincts seront créés par MySQL Cluster. Un index sera un hash utilisé pour les accès aux lignes, et pour le verrouillage. Il est aussi utilisé pour les contraintes d'unicité.
La taille d'un index hash est de 25 octets plus la taille de la clé primaire. Pour les clés primaires dont la taille dépasse 32 octets, ajoutez un autre 8 octets pour des références internes.
Par exemple, observons la table suivante.

Sélectionnez

CREATE TABLE example
(
    a INT NOT NULL,
    b INT NOT NULL,
    c INT NOT NULL,
    PRIMARY KEY(a),
    UNIQUE(b)
) ENGINE=NDBCLUSTER;

Nous avons ici 12 octets d'entête (puisque des colonnes non nulles économisent 4 octets), plus 12 octets par ligne. De plus, nous avons deux index ordonnés sur les colonnes a et b, qui utilisent chacun 10 octets par ligne. Nous aurons aussi une clé primaire hash avec environ 29 octets par ligne. La contrainte unique est implémentée par une table séparée, avec b comme clé primaire et a comme colonne. Cette table va donc consommer encore 29 autres octets en mémoire par ligne, plus 12 octets d'entête et 8 octets pour les données.

Pour une table d'un million de lignes, nous aurons besoin de 58 Mo de mémoire pour gérer les index en mémoire, la clé primaire et la contrainte d'unicité. Pour DataMemory, nous aurons besoin de 64 Mo de mémoire, pour gérer les lignes de la table de base et celles de la table d'index, plus les deux tables d'index ordonnés.

En conclusion, les index hash consomment beaucoup d'espace en mémoire vive, mais fournissent un accès accéléré aux données. Ils sont aussi utilisés dans les clusters MySQL pour gérer les contraintes d'unicité.

Actuellement, les seuls algorithmes de partitionnement sont le hashage et les index ordonnés, qui sont locaux à chaque nœud, et ne peuvent pas prendre en compte les contraintes d'unicité en général.

Un point important pour les deux options IndexMemory et DataMemory est que le total de la base de données est la taille de DataMemory et IndexMemory dans chaque groupe. Chaque groupe est utilisé pour stocker les informations répliquées, ce qui fait que si vous avez 4 nœuds avec 2 répliques, cela fait 2 groupes de nœuds, et le total de DataMemory disponible est 2*DataMemory dans chaque nœud.

Un autre aspect important est les modifications de DataMemory et IndexMemory. Tout d'abord, il est fortement recommandé d'avoir la même quantité de DataMemory et IndexMemory sur tous les nœuds. Comme les données sont distribuées équitablement entre les nœuds du cluster, l'espace disponible n'est pas supérieur à la plus petite quantité d'espace disponible sur un des nœuds du cluster, multiplié par le nombre de groupe de nœuds.

DataMemory et IndexMemory peuvent être modifiés, mais il est dangereux de le réduire, car cela peut conduire à des problèmes de redémarrage pour un nœud, ou même pour le cluster, car il n'y aura plus assez de mémoire pour restaurer les tables. Accroître les valeurs doit être facile à faire, mais il est recommandé, pour ce type de mise à jour, de faire une modification comparable à une mise à jour du logiciel : modification du fichier de configuration, puis redémarrage du serveur de gestion, et chaque serveur est relancé manuellement, un à la fois.

IndexMemory n'est pas utilisé à cause des modifications, mais à cause des insertions : ces dernières sont insérées immédiatement, alors que les effacements ne sont pris en compte que lorsque la transaction est archivée.

La valeur par défaut de IndexMemory est 18 Mo. La taille minimale est de 1 Mo.

Les trois paramètres suivants sont importants, car ils affectent le nombre de transactions simultanées et la taille des transactions qui peuvent être gérées par le système. MaxNoOfConcurrentTransactions fixe le nombre de transactions simultanées dans un nœud, et MaxNoOfConcurrentOperations fixe le nombre de lignes qui peuvent être en phase de modification ou de verrouillage simultanément.

Ces deux paramètres, et particulièrement MaxNoOfConcurrentOperations seront étudiés de près par les utilisateurs qui choisissent des valeurs particulières, et évitent les valeurs par défaut. La valeur par défaut est configurée pour les systèmes ayant de petites transactions, et s'assure que la mémoire n'est pas trop sollicitée.

[DB]MaxNoOfConcurrentTransactions
Pour chaque transaction active dans le cluster, il y a besoin d'une ligne de transaction dans l'un des nœuds du cluster. Le rôle de cette coordination de transaction est réparti entre tous les nœuds et ainsi, le nombre de lignes de transactions dans le cluster est le nombre de nœuds dans le cluster.
En fait, les lignes de transactions sont allouées aux serveurs MySQL. Normalement, il y a au moins une ligne de transaction allouée dans le cluster par connexion qui utilise ou a utilisé une table dans le cluster. Par conséquent, il faut s'assurer qu'il y a plus de lignes de transaction dans le cluster qu'il n'y a de connexions simultanées à tous les serveurs du cluster MySQL.
Ce paramètre doit être le même pour tous les nœuds du serveur.
Modifier ce paramètre n'est jamais facile, et peut conduire à un crash du système. Lorsqu'un nœud crashe, le nœud le plus ancien va prendre en charge l'état des transactions qui avaient lieu dans le nœud perdu. Il est donc important que ce nœud ait autant de lignes de transactions que le nœud perdu.
La valeur par défaut pour ce paramètre est 4096.
[DB]MaxNoOfConcurrentOperations
Ce paramètre est sujet à modifications par les utilisateurs. Les utilisateurs qui effectuent des transactions courtes et rapides n'ont pas besoin de lui donner une valeur trop haute. Les applications qui veulent utiliser des transactions de grande taille impliquant de nombreuses lignes devront accroître sa valeur.
Pour chaque transaction qui modifie des données dans le cluster, il faut allouer des lignes d'opération. Il y a des lignes d'opération au niveau de la coordination de transaction, et dans les nœuds où les transformations ont lieu.
Les lignes d'opération contiennent des informations d'état qui doivent être capables de retrouver des lignes d'annulation, des files de verrous et toutes les autres informations d'état.
Pour dimensionner le cluster afin de gérer des transactions où un million de lignes doivent être mises à jour simultanément, il faut donner à ce paramètre la valeur d'un million divisé par le nombre de nœuds. Pour un cluster ayant 4 nœuds de stockage, la valeur sera donc de 250 000.
De plus, les lectures qui posent des verrous utilisent aussi des lignes d'opération. De la mémoire supplémentaire est allouée dans les nœuds locaux pour gérer les cas où la distribution n'est pas parfaite entre les nœuds.
Lorsqu'une requête impose l'utilisation d'un index hash unique, il y aura automatiquement deux lignes d'opération pour chaque ligne de la transaction. La première représente la lecture dans la table d'index, et la seconde gère l'opération dans la table de base.
La valeur par défaut pour ce paramètre est 32 768.
Ce paramètre gère en fait deux aspects qui peuvent être configurés séparément. Le premier aspect spécifie le nombre de lignes d'opération qui peuvent être placées dans la coordination de transaction. Le second aspect spécifie le nombre de lignes d'opération qui seront utilisées dans la base de données locale.
Si une très grande transaction est effectuée sur un cluster de 8 nœuds, elle aura besoin d'autant de lignes d'opération pour la coordination de transactions qu'il y a de lectures, modifications et effacements impliqués dans la transaction. La transaction va répartir les lignes d'opération entre les 8 nœuds. Par conséquent, s'il est nécessaire de configurer le système pour une grosse transaction, il est recommandé de configurer les nœuds séparément. MaxNoOfConcurrentOperations va toujours être utilisé pour calculer le nombre de lignes d'opération dans la coordination de transaction.
Il est aussi important d'avoir une idée des contraintes de mémoire pour ces lignes d'opération. En MySQL 4.1.5, les lignes d'opération consomment 1 Ko par ligne. Ce chiffre est appelé à réduire dans les versions 5.x.
[DB]MaxNoOfLocalOperations
Par défaut, ce paramètre est calculé comme 1,1 fois MaxNoOfConcurrentOperations ce qui est bon pour les systèmes avec de nombreuses requêtes simultanées, de petite taille. Si la configuration doit gérer une très grande transaction une fois de temps en temps, et qu'il y a de beaucoup de nœuds, il est alors recommandé de configurer cette valeur séparément.

Le jeu de paramètres suivant est utilisé pour le stockage temporaire durant l'exécution d'une requête dans le cluster. Toute cette mémoire sera libérée lorsque la requête sera terminée, et que la transaction attendra l'archivage ou l'annulation.

La plupart des valeurs par défaut de ces paramètres seront valables pour la plupart des utilisateurs. Certains utilisateurs exigeants pourront augmenter ces valeurs pour améliorer le parallélisme du système, et les utilisateurs plus contraints pourront réduire les valeurs pour économiser de la mémoire.

[DB]MaxNoOfConcurrentIndexOperations
Pour les requêtes utilisant un index unique hash, un autre jeu de lignes d'opération sont temporairement utilisés durant la phase d'exécution de la requête. Ce paramètre configure la taille de la file qui accueille ces lignes. Par conséquent, cette mémoire n'est utilisée que lors de l'exécution d'une requête, et dès la fin de l'exécution, les lignes sont libérées. L'état nécessaire pour gérer les annulations et archivages est géré par les lignes d'opération permanentes, où la taille de la file est gérée par MaxNoOfConcurrentOperations.
La valeur par défaut pour ce paramètre est 8192. Seules les situations où un très haut niveau de parallélisme utilisant des index uniques hash doivent augmenter cette valeur. La réduction de cette valeur permet d'économiser de la mémoire, si l'administrateur est certain que le parallélisme reste rare dans le cluster.
[DB]MaxNoOfFiredTriggers
La valeur par défaut pour MaxNoOfFiredTriggers est 4000. Normalement, cette valeur doit être suffisante pour la plupart des systèmes. Dans certains cas, il est possible de réduire cette valeur si le parallélisme n'est pas trop haut dans le cluster.
Cette option est utilisée lorsqu'une opération est effectuée, et affecte un index hash unique. Modifier une colonne qui fait partie d'un index unique hash ou insérer/effacer une ligne dans une table avec un index unique hash va déclencher une insertion ou un effacement dans l'index de la table. Cette ligne est utilisée durant l'attente de la fin de l'exécution de cette opération. C'est une ligne qui ne dure pas longtemps, mais elle peut malgré tout réclamer plusieurs lignes pour des situations temporaires d'écritures parallèles sur la table de base, contenant les index uniques.
[DB]TransactionBufferMemory
Ce paramètre est aussi utilisé pour lister les opérations de modifications d'index. Elle garde les informations de clé et colonne de l'opération en cours. Il doit être exceptionnel de modifier ce paramètre.
De plus, les opérations de lecture et écriture utilisent un buffer similaire. Ce buffer est encore plus temporaire dans son utilisation, ce qui fait que c'est un paramètre de compilation, qui vaut 4000*128 octets (500Ko). Le paramètre st ZATTRBUF_FILESIZE dans Dbtc.hpp. Un buffer similaire pour les informations de clé, qui représente 4000*16 octets, soit 62.5 ko d'espace. Ce paramètre est ZDATABUF_FILESIZE dans Dbtc.hpp. Dbtc est le module qui gère la coordination de transaction.
Des paramètres similaires existent dans le module Dblqh pour gérer les lectures et modifications lorsque les données ont été localisées. Dans Dblqh.hpp avec ZATTRINBUF_FILESIZE qui vaut 10000*128 octets (1250 ko) et ZDATABUF_FILE_SIZE, qui vaut 10000*16 octets (environ 156 ko). Nous n'avons aucune connaissance de situation qui soit limitée par ces valeurs.
La valeur par défaut de TransactionBufferMemory est 1 Mo.
[DB]MaxNoOfConcurrentScans
Ce paramètre est utilisé pour contrôler la quantité de scans parallèles qui sont effectués dans le cluster. Chaque coordination de transaction peut gérer un certain nombre de scans de tables simultanément, et ce nombre est limité par cette option. Chaque partition va utiliser une ligne de scan dans le nœud où la partition est située. Le nombre de lignes est la taille de ce paramètre multiplié par le nombre de nœuds, ce qui fait que le cluster peut supporter le nombre maximal de scans, multiplié par le nombre de nœuds du cluster.
Les scans sont effectués dans deux situations. La première est lorsqu'aucun index hash ou ordonné n'a pu être trouvé pour gérer la requête. Dans ce cas, la requête est exécutée avec un scan de table. La seconde est lorsqu'il n'y a pas d'index hash, mais seulement un index ordonné. Utiliser l'index ordonné, revient à faire un scan de tables parallèles. Comme l'ordre n'est conservé que dans les partitions locales, il est nécessaire de faire le scan dans toutes les partitions.
La valeur par défaut de MaxNoOfConcurrentScans est 256. La valeur maximale est de 500.
Ce paramètre va toujours spécifier le nombre de scans possibles dans la coordination de transaction. Si le nombre local de scans n'est pas fourni, il est calculé comme le produit de MaxNoOfConcurrentScans et du nombre de nœuds de stockages du système.
[DB]MaxNoOfLocalScans
Il est possible de spécifier le nombre de lignes de scan locaux, si les scans ne sont pas totalement parallèles.
[DB]BatchSizePerLocalScan
Ce paramètre est utilisé pour calculer le nombre de lignes de verrous qui est nécessaire pour gérer les opérations de scan courantes.
La valeur par défaut est 64 et cette valeur est très liée au paramètre ScanBatchSize défini dans l'interface des nœuds.
[DB]LongMessageBuffer
Ceci est un buffer interne utilisé pour passer des messages aux nœuds, et entre les nœuds. Il est hautement improbable que quiconque veuille modifier cette valeur, mais il est malgré tout disponible. Par défaut, ce paramètre vaut 1 Mo.
[DB]NoOfFragmentLogFiles
Ceci est un paramètre important qui indique la taille du fichier de logs de REDO. Les logs REDO sont organisés en boucle, et il est important que la fin et le début ne se chevauchent pas. Lorsque la queue et la tête se rapprochent dangereusement l'un de l'autre, le nœud va commencer à annuler les modifications, car il n'y a plus de place pour les lignes de modifications.
Le log de REDO n'est supprimé que lorsque trois jalons locaux sont passés depuis l'insertion dans le log. La vitesse d'apparition d'un jalon est contrôlée par un jeu de paramètres : tous ces paramètres sont donc liés.
La valeur par défaut de ce paramètre est 8, ce qui signifie que 8 jeux de 4*16 Mo fichiers. Cela représente un total de 512 Mo. L'unité de stockage est de 64 Mo pour le log de REDO. Dans les serveurs à fort taux de modification, il faut augmenter considérablement cette valeur. Nous avons vu des cas de test où il a fallu mettre cette valeur à plus de 300.
Si les jalons sont lents à venir, et qu'il y a tellement d'écritures dans la base que les fichiers de logs sont remplis, que le fichier de logs de queue ne peut pas être supprimé pour assurer la restauration, les transactions de modification seront interrompues avec une erreur interne 410, qui sera transformée en message : Out of log file space temporarily. Cette condition restera en place jusqu'à ce qu'un jalon soit atteint, et que la queue du log puisse avancer.
[DB]MaxNoOfSavedMessages
Ce paramètre limite le nombre de fichiers de trace qui seront conservés sur le serveur, avant de remplacer un ancien fichier de trace. Les fichiers de trace sont générés lorsque le nœud crashe pour une raison donnée.
La valeur par défaut est de 25 fichiers de trace.

Le jeu de paramètres suivant définit la taille du buffer d'objets de métadonnées. Il est nécessaire de définir le nombre maximal d'objets, d'attributs, d'index et d'objets triggers utilisés par les index, les événements, et la réplication entre clusters.

[DB]MaxNoOfAttributes
Ce paramètre définit le nombre d'attributs qui peuvent être définis dans le cluster.
La valeur par défaut pour ce paramètre est 1000. La valeur minimale est 32 et il n'y a pas de maximum. Chaque attribut consomme environ 200 octets d'espace, car les métadonnées sont totalement répliquées entre les nœuds.
[DB]MaxNoOfTables
Un objet de table est alloué pour chaque table, pour chaque index hash unique et pour chaque index ordonné. Ce paramètre fixe le nombre maximal d'objets de table qui soit alloué.
Pour chaque attribut qui contient un type de données BLOB, une autre table est utilisée pour stocker la partie principale des données BLOB. Ces tables doivent aussi être prises en compte lorsque vous définissez les tables.
La valeur par défaut pour ce paramètre est 128. La valeur minimale est de 8, et il n'y a pas de maximum. Il y a des limitations internes, qui empêchent d'aller au-delà de 1600. Chaque objet de table consomme environ 20 ko de mémoire par nœud.
[DB]MaxNoOfOrderedIndexes
Pour chaque index ordonné dans le cluster, des objets sont alloués pour décrire ce qu'ils indexent et leur stockage. Par défaut, chaque index défini aura un index ordonné associé. Les index uniques et les clés primaires ont tous deux un index ordonné et un index hash.
La valeur par défaut pour ce paramètre est 128. Chaque objet consomme environ 10 ko par nœud.
[DB]MaxNoOfUniqueHashIndexes
Pour chaque index unique (pas pour les index primaires), une table spéciale est allouée pour assurer la correspondance entre la clé primaire et la clé unique de la table indexée. Par défaut, il y aura un index ordonné de défini pour chaque index unique. Pour éviter cela, utilisez l'option USING HASH.
La valeur par défaut de 64. Chaque index va consommer environ 15 ko par nœud.
[DB]MaxNoOfTriggers
Pour chaque index hash unique, un trigger interne de modification, insertion ou effacement est alloué. Cela fait 3 triggers pour chaque index hash unique. Les index ordonnés utilisent un seul objet trigger. Les sauvegardes utilisent aussi trois objets trigger pour chaque table normale dans le cluster. Lorsque la réplication entre cluster est supportée, elle va aussi utiliser un trigger interne.
Ce paramètre limite le nombre d'objets trigger dans le cluster.
La valeur par défaut pour ce paramètre est 768.
[DB]MaxNoOfIndexes
Ce paramètre est abandonné depuis MySQL 4.1.5. Il faut désormais utiliser MaxNoOfOrderedIndexes et MaxNoOfUniqueHashIndexes à la place.
Ce paramètre ne sert que pour les index hash uniques. Il faut une ligne dans ce buffer pour chaque index hash unique défini dans le cluster.
La valeur par défaut pour ce paramètre est 128.

Il y a un jeu de paramètres booléens qui affectent le comportement des nœuds de stockage. Les paramètres booléens peuvent être spécifiés à true avec Y (pour Yes, c'est-à-dire oui) ou 1, et à false avec N (pour non) ou 0.

[DB]LockPagesInMainMemory
Pour certains systèmes d'explications tels que Solaris et Linux, il est possible de verrouiller un processus en mémoire et éviter les problèmes de swap. C'est une fonctionnalité importante pour améliorer le temps réel du cluster.
Par défaut, cette fonctionnalité n'est pas activée.
[DB]StopOnError
Ce paramètre indique si le processus doit s'arrêter sur une erreur, ou s'il doit faire un redémarrage automatique.
Par défaut, cette fonctionnalité est activée.
[DB]Diskless
Dans les interfaces internes, il est possible de configurer les tables comme sans disque (littéralement, diskless), ce qui signifie que les tables ne sont pas enregistrées sur le disque, et qu'aucun log n'est fait. Ces tables existent uniquement en mémoire. Ces tables existeront encore après un crash, mais pas leur contenu.
Cette fonctionnalité fait que le cluster entier devient Diskless, ce qui fait que les tables n'existent plus après un crash. Activer cette fonctionnalité de fait avec Y ou 1.
Lorsque cette fonctionnalité est activée, les sauvegardes sont faites, mais elles ne seront pas stockées, car il n'y a pas de disque. Dans les versions futures, il est probable que les sauvegardes sans disques soient une option séparée.
Par défaut, cette fonctionnalité n'est pas activée.
[DB]RestartOnErrorInsert
Cette fonctionnalité n'est possible que lorsque la version de débogage a été compilée, pour pouvoir insérer des erreurs à différents points de l'exécution, afin de tester les cas d'erreurs.
Par défaut, cette fonctionnalité n'est pas activée.

Il y a plusieurs paramètres pour tester les délais d'expiration et les intervalles entre différentes actions des nœuds de stockage. Plusieurs délais d'expiration sont spécifiés en millisecondes, à quelques exceptions qui sont explicitement indiquées.

[DB]TimeBetweenWatchDogCheck
Pour s'assurer que le thread principal ne reste back éternellement bloqué dans une boucle infinie, il existe un garde-fou qui vérifie le fonctionnement de ce thread. Ce paramètre indique le nombre de millisecondes entre deux vérifications. Après trois essais où le processus est dans le même état, le thread est arrêté par le garde-fou.
Ce paramètre peut être facilement modifié, et peut différer de nœud en nœud, même s'il y a peu de raison pour faire des traitements différents.
La durée par défaut est de 4000 millisecondes (4 secondes).
[DB]StartPartialTimeout
Ce paramètre spécifie le temps durant lequel le cluster attend les nœuds de stockage avant que l'algorithme de cluster soit appelé. Cette durée est appelée pour éviter de démarrer un cluster partiel.
La valeur par défaut de 30 000 millisecondes (30 secondes). 0 signifie l'éternité, c'est-à-dire que tous les nœuds doivent être là pour démarrer.
[DB]StartPartitionedTimeout
Si le cluster est prêt à démarrer après avoir attendu StartPartialTimeout, mais qu'il est possible qu'il soit dans un état de partitionnement, alors le cluster attend encore ce délai supplémentaire.
Le délai par défaut est de 60 000 millisecondes (60 secondes).
[DB]StartFailureTimeout
Si le démarrage n'est pas réalisé dans le délai spécifié par ce paramètre, le démarrage du nœud échouera. En donnant la valeur de 0 à ce paramètre, il n'y a pas de délai appliqué.
La valeur par défaut de 60 000 millisecondes (60 secondes). Pour les nœuds de stockage avec de grandes bases de données, il faut augmenter cette valeur, car le nœud peut demander jusqu'à 15 minutes pour effectuer le démarrage de plusieurs gigaoctets de données.
[DB]HeartbeatIntervalDbDb
Une des méthodes qui permettent de découvrir les nœuds morts est la tachycardie (littéralement, heartbeats, battements de cœur). Ce paramètre indique le nombre de signaux qui sont envoyés, et la fréquence supposée de réception. Après avoir sauté 3 intervalles de signaux d'affilée, le nœud est déclaré mort. Par conséquent, le temps maximal de détection d'un nœud est de 4 battements.
L'intervalle par défaut est de 1500 millisecondes (1,5 seconde). Ce paramètre ne doit pas être modifié de trop. Si vous utilisez 5000 millisecondes et que le nœud observé utiliser une valeur de 1000 millisecondes alors ce dernier sera rapidement déclaré mort. Ce paramètre peut être modifié progressivement, mais pas trop d'un coup.
[DB]HeartbeatIntervalDbApi
Similairement, chaque nœud de stockage émet des signaux de vie pour chaque serveur MySQL connecté, pour s'assurer qu'ils fonctionnent correctement. Si un serveur MySQL ne renvoie pas un signal dans le temps escompté, avec le même algorithme que pour la surveillance des nœuds de stockage, il est alors déclaré mort, et les transactions sont alors terminées, les ressources libérées, et le serveur ne pourra pas se reconnecter avant la fin des opérations de nettoyage.
La valeur par défaut pour cet intervalle est 1500 millisecondes. Cet intervalle peut être différent pour le nœud de stockage, car chaque nœud de stockage fonctionne indépendamment des autres nœuds de stockage qui surveillent le serveur connecté.
[DB]TimeBetweenLocalCheckpoints
Ce paramètre est une exception, en ce sens qu'il ne définit pas un délai avant de poser un jalon local. Ce paramètre sert à s'assurer que dans un cluster, le niveau de modification des tables n'est pas trop faible pour empêcher la pose de jalon. Dans la plupart des clusters avec un taux de modification important, il est probable que les jalons locaux soient posés immédiatement après la fin du précédent.
La taille de toutes les opérations d'écriture exécutées depuis le début du jalon précédent est sommée. Ce paramètre est spécifié comme le logarithme du nombre de mots. Par exemple, la valeur par défaut de 20 signifie que 4 Mo d'opérations d'écriture ont été faites ; 21 représente 8 Mo, et ainsi de suite. La valeur maximale de 31 représente 8 Go d'opérations.
Toutes les opérations d'écritures dans le cluster sont additionnées ensemble. En lui donnant une valeur de 6 ou moins, cela va forcer les écritures de jalons continuellement, sans aucune attente entre deux jalons, et indépendamment de la charge du cluster.
[DB]TimeBetweenGlobalCheckpoints
Lorsqu'une transaction est archivée, elle est placée en mémoire principale de tous les nœuds où des données miroirs existent. Les lignes de logs de la transaction ne sont pas forcées sur le disque lors de l'archivage. L'idée ici est que pour que la transaction soit archivée sans problème, il faut qu'elle soit archivée dans 2 nœuds indépendants.
Dans le même temps, il est important de s'assurer que dans le pire cas de crash, le cluster se comporte correctement. Pour s'assurer que les transactions dans un intervalle de temps donné sont placées dans un jalon global. Un groupe entier de transactions est envoyé sur le disque. Par conséquent, la transaction a été placée dans un groupe de jalon, en tant que partie d'un archivage. Ultérieurement, ce groupe de log sera placé sur le disque, et le groupe entier de transactions sera archivé sur tous les serveurs.
Ce paramètre spécifie l'intervalle entre les jalons globaux. La valeur par défaut est de 2000 millisecondes.
[DB]TimeBetweenInactiveTransactionAbortCheck
Un délai d'expiration est appliqué pour chaque transaction en fonction de ce paramètre. Par conséquent, si ce paramètre vaut 1000 millisecondes, alors chaque transaction sera vérifiée une fois par seconde.
La valeur par défaut pour ce paramètre est 1000 millisecondes (1 seconde).
[DB]TransactionInactiveTimeout
Si la transaction n'est pas en exécution de requête, mais attend d'autres données, ce paramètre spécifie le temps maximum d'attente des données avant d'annuler la transaction.
Par défaut, ce paramètre ne limite pas l'arrivée des données. Pour des clusters en production, qui doivent s'assurer qu'aucune transaction ne bloque le serveur durant trop longtemps, il faut utiliser une valeur basse. L'unité est la milliseconde.
[DB]TransactionDeadlockDetectionTimeout
Lorsqu'une transaction est impliquée dans l'exécution d'une requête, elle attend les autres nœuds. Si les autres nœuds ne répondent pas, il peut se passer 3 choses. Premièrement, le nœud peut être mort ; deuxièmement, l'opération peut être placée dans une file d'attente de verrous ; troisièmement, le nœud impliqué peut être surchargé. Ce paramètre limite la durée de l'attente avant d'annuler la transaction.
Ce paramètre est important pour la détection d'échec de nœud et le blocage de verrou. En le configurant trop haut, il est possible de laisser passer des blocages.
La durée par défaut est de 1200 millisecondes (1.2 seconde).
[DB]NoOfDiskPagesToDiskAfterRestartTUP
Lors de l'exécution d'un jalon local, l'algorithme envoie toutes les pages de données au disque. Les envoyer aussi rapidement que possible cause des charges inutiles sur le processeur, le réseau et le disque. Cette option contrôle le nombre de pages à écrire par 100 millisecondes. Une page est définie ici comme faisant 8 ko. C'est l'unité de ce paramètre est de 80 ko par seconde. En lui donnant la valeur de 20, cela représente 1.6 Mo de données envoyées sur le disque par seconde, durant un jalon local. De plus, l'écriture des logs de UNDO est incluse dans cette somme. L'écriture des pages d'index (voir IndexMemory pour comprendre comment les pages d'index sont utilisées), et leurs logs d'UNDO sont gérés par le paramètre NoOfDiskPagesToDiskAfterRestartACC. Ce paramètre gère les limitations d'écriture de DataMemory.
Ainsi, ce paramètre spécifie la vitesse d'écriture des jalons. Ce paramètre est important et est corrélé à NoOfFragmentLogFiles, DataMemory, IndexMemory.
La valeur par défaut de 40 (3.2 Mo de pages de données par seconde).
[DB]NoOfDiskPagesToDiskAfterRestartACC
Ce paramètre a la même unité que NoOfDiskPagesToDiskAfterRestartTUP, mais limite la vitesse d'écriture des pages d'index depuis IndexMemory.
La valeur par défaut pour ce paramètre est 20 (1.6 Mo par seconde).
[DB]NoOfDiskPagesToDiskDuringRestartTUP
Ce paramètre spécifie les mêmes limitations que NoOfDiskPagesToDiskAfterRestartTUP et NoOfDiskPagesToDiskAfterRestartACC, mais s'applique aux jalons locaux, exécutés sur un nœud comme une partie de jalon lors du redémarrage. Faisant partie du redémarrage, un jalon local est toujours effectué. Il est possible d'utiliser une vitesse accrue durant le redémarrage du nœud, car les activités sont alors limitées sur le serveur.
Ce paramètre gère la partie de DataMemory.
La valeur par défaut de 40 (3.2 Mo par seconde).
[DB]NoOfDiskPagesToDiskDuringRestartACC
Durant le redémarrage de la partie locale de IndexMemory pour un jalon local.
La valeur par défaut de 20 (1.6 Mo par seconde).
[DB]ArbitrationTimeout
Ce paramètre spécifie le temps que le nœud de stockage va attendre un message de l'arbitre lors d'un fractionnement du réseau.
La valeur par défaut de 1000 millisecondes (1 seconde).

De nombreux nouveaux paramètres de configuration ont été introduits en MySQL 4.1.5. Ils correspondent à des valeurs qui étaient auparavant configurées durant la compilation. La raison principale à cela est qu'elles permettent aux utilisateurs experts de contrôler la taille du processus et d'ajuster les différentes tailles de buffer, en fonction de ses besoins.

Tous ces buffers sont utilisés comme interface avec le système de fichiers lors de l'écriture des lignes de log sur le disque. Si le nœud fonctionne en mode sans disque, ces paramètres peuvent prendre leur valeur minimale, car les écritures sur le disque sont simulées et toujours validées par la couche d'abstraction du moteur NDB.

[DB]UndoIndexBuffer
Ce buffer est utilisé durant les jalons locaux. Le moteur de stockage NDB utilise un mécanisme de restauration basé sur des jalons cohérents avec le log de REDO. Afin de produire un jalon valide sans bloquer le système, l'enregistrement des UNDO est fait durant l'exécution des jalons locaux. Le log de UNDO n'est activé que pour un fragment de table à chaque fois. Cette optimisation est rendue possible, car les tables sont entièrement stockées en mémoire principale.
Ce buffer est utilisé pour les modifications dans les index hash de clé primaire. Les insertions et les effacements réarrangent les index hash, et le moteur NDB écrit les logs d'UNDO qui associent les modifications physiques avec un index de page pour qu'ils puissent être appliqués même après un redémarrage. Toutes les insertions actives sont aussi enregistrées au début d'un jalon local, pour chaque fragment.
Les lectures et modifications ne font que poser des bits de verrouillage, et altèrent un entête dans la ligne d'index. Ces modifications sont gérées par l'algorithme d'écriture des pages, pour s'assurer que ces opérations n'ont pas besoin du log d'UNDO.
Ce buffer vaut 2 Mo par défaut. La valeur minimale est 1 Mo. Pour la plupart des applications, c'est suffisant. Les applications qui font beaucoup d'insertions et d'effacement avec de grandes transactions en exploitant intensivement leurs clés primaires devront agrandir ce buffer.
Si le buffer est trop petit, le moteur NDB émet une erreur de code 677 qui se traduit par « Index UNDO buffers overloaded ».
[DB]UndoDataBuffer
Ce buffer a exactement le même rôle que UndoIndexBuffer, mais est utilisé pour les données. Ce buffer est utilisé durant l'exécution d'un jalon local pour un fragment de table, et les insertions, les effacements et les modifications utilisent ce buffer.
Comme les lignes du log d'UNDO tendent à être plus grandes et que plus d'informations sont stockées, ce buffer doit être aussi de plus grande taille. Par défaut, il vaut 16 Mo. Pour certaines applications, cela peut être surdimensionné, et il est alors recommandé de réduire cette valeur. La taille minimale est de 1 Mo. Il sera rare d'avoir à augmenter cette valeur. Si cette valeur doit être augmentée, commencez par vérifier vos disques et leurs performances. Si ce sont les disques qui limitent le débit, le buffer sera alors bien dimensionné.
Si ce buffer est trop petit et se remplit, le moteur NDB émet une erreur de code 891 qui se traduit par "Data UNDO buffers overloaded".
[DB]RedoBuffer
Toutes les activités de modification doivent être enregistrées. Cela permet de repasser ces opérations au redémarrage du système. L'algorithme de restauration utilise un jalon cohérent, produit par un jalon « flou » produit par les données couplées aux pages de log d'UNDO. Puis, le log de REDO est appliqué pour rejouer toutes les modifications qui ont eu lieu depuis le redémarrage du système.
Ce buffer fait 8 Mo par défaut. Sa taille minimale est de 1 Mo.
Si ce buffer est trop petit, le moteur NDB émet une erreur de code 1221 qui se traduit par : "REDO log buffers overloaded".

Pour la gestion du cluster, il est important de pouvoir contrôler la quantité de messages de logs qui sont envoyés à stdout par les différents événements qui surviennent. Les événements seront bientôt listés dans ce manuel. Il y a 16 niveaux possibles, allant de 0 à 15. En utilisant un niveau de rapport d'erreur de 15, toutes les erreurs seront rapportées. Un niveau de rapport d'erreur nul (0) bloquera toutes les erreurs.

La raison qui fait que la plupart des valeurs par défaut sont à 0, et qu'elles ne causent aucun affichage sûr est que le même message est envoyé au log du cluster sur le serveur de gestion. Seul le message de démarrage est envoyé à stdout.

Un jeu de niveau d'erreur similaire peut être configuré dans le client de gestion, pour définir les niveaux d'erreurs qui doivent rejoindre le log du cluster.

[DB]LogLevelStartup
Événements générés durant le démarrage du processus.
Le niveau par défaut est 1.
[DB]LogLevelShutdown
Événements générés durant l'extinction programmée d'un nœud.
Le niveau par défaut est 0.
[DB]LogLevelStatistic
Événements statistiques tels que le nombre de clés primaires lues, le nombre d'insertions, modifications et de nombreuses autres informations statistiques sur l'utilisation des buffers.
Le niveau par défaut est 0.
[DB]LogLevelCheckpoint
Événements générés par les jalons locaux et globaux.
Le niveau par défaut est 0.
[DB]LogLevelNodeRestart
Événements générés par un redémarrage de nœud.
Le niveau par défaut est 0.
[DB]LogLevelConnection
Événements générés par les connexions entre les nœuds dans le cluster.
Le niveau par défaut est 0.
[DB]LogLevelError
Événements générés par les erreurs et alertes dans le cluster. Ces erreurs ne sont pas causées par un échec de nœud, mais sont suffisamment importantes pour être rapportées.
Le niveau par défaut est 0.
[DB]LogLevelInfo
Événements générés pour informer sur l'état du cluster.
Le niveau par défaut est 0.

Il existe un jeu de paramètres qui définissent les buffers mémoire qui sont utilisés pour l'exécution des sauvegardes en ligne.

[DB]BackupDataBufferSize
Lors de l'exécution d'une sauvegarde, il y a deux buffers utilisés pour envoyer des données au disque. Ce buffer sert à rassembler des données obtenues par le scan des tables du nœud. Lorsque le regroupement atteint un certain niveau, ces pages sont envoyées au disque. Ce niveau est spécifié par le paramètre BackupWriteSize. Lors de l'envoi des données sur le disque, la sauvegarde continue de remplir ce buffer, jusqu'à ce qu'il n'y ait plus de place. Lorsque la place manque, la sauvegarde marque une pause, et attend que l'écriture ait libéré de la mémoire avant de poursuivre.
La valeur par défaut de 2 Mo.
[DB]BackupLogBufferSize
Ce paramètre a un rôle similaire, mais sert à écrire un log de toutes les écritures dans la table durant l'exécution de la sauvegarde. Le même principe s'applique à l'écriture de ces pages que pour BackupDataBufferSize, hormis le fait que lorsque la place manque, la sauvegarde échoue par manque de place. Par conséquent, la taille de ce buffer doit être assez grande pour encaisser la charge causée par les activités d'écriture durant l'exécution de la sauvegarde.
La valeur par défaut de ce paramètre doit être assez grande. En fait, il est plus probable qu'une erreur de sauvegarde soit causée par le disque qui ne peut suivre la vitesse d'écriture. Si le disque est sous-dimensionné pour cette opération, le cluster aura du mal à satisfaire les besoins des autres opérations.
Il est important de dimensionner les nœuds pour que les processeurs deviennent les facteurs limitant, bien plus que les disques ou le réseau.
La valeur par défaut de 2 Mo.
[DB]BackupMemory
Ce paramètre est simplement la somme des deux précédents : BackupDataBufferSize et BackupLogBufferSize.
La valeur par défaut de 4 Mo.
[DB]BackupWriteSize
Ce paramètre spécifie la taille des messages d'écriture sur le disque, pour le log, ainsi que le buffer utilisé pour les sauvegardes.
La valeur par défaut de 32 ko.

16-4-4-6. Définition des serveurs MySQL dans un Cluster MySQL▲

La section [API] (et son alias [MYSQLD]) définit le comportement du serveur MySQL. Aucun paramètre n'est obligatoire. Si aucun ordinateur ou nom d'hôte n'est fourni, alors tous les hôtes pourront utiliser ce nœud.

[API]Id
Cet identifiant est celui du nœud, qui sert comme adresse pour les messages internes du cluster. C'est un entier compris entre 1 et 63. Chaque nœud du cluster doit avoir une identité distincte.
[API]ExecuteOnComputer
Cette valeur fait référence à un des ordinateurs définis dans la section computer.
[API]ArbitrationRank
Ce paramètre sert à définir les nœuds qui jouent le rôle d'arbitre. Les nœuds MGM et les nœuds API peuvent être des arbitres. 0 signifie qu'il n'est pas utilisé comme arbitre, 1 est la priorité haute, et 2 la priorité basse. Une configuration normale utilise un serveur de gestion comme arbitre, en lui donnant un ArbitrationRank de 1 (ce qui est le défaut), et en mettant tous les nœuds API à 0 (ce n'est pas le comportement par défaut en MySQL 4.1.3).
[API]ArbitrationDelay
En donnant une valeur différente de 0 à cette option, le serveur de gestion va retarder ses réponses d'arbitrage. Par défaut, le délai est nul, et c'est très bien comme cela.
[API]BatchByteSize
Pour les requêtes qui deviennent des analyses complètes de table ou des analyses d'intervalle, il est important pour les performances de lire les lignes par groupe. Il est possible de configurer la taille de ce groupe en termes de nombre de lignes et de taille de données (en octets). La taille réelle du groupe sera limitée par les deux paramètres.
La vitesse des requêtes peut varier de près de 40 % en fonction de la valeur de ce paramètre. Dans les versions futures, le serveur MySQL fera les estimations nécessaires pour configurer ces paramètres lui-même.
Ce paramètre est mesuré en octets, et par défaut, il vaut 32 KB.
[API]BatchSize
Ce paramètre est le nombre de lignes et il vaut par défaut 64. La valeur maximale est 992.
[API]MaxScanBatchSize
La taille du groupe est la taille de chaque groupe envoyé par chaque nœud de stockage. La plupart des analyses sont effectuées en parallèle : pour protéger le serveur MySQL d'un afflux monstrueux de données, ce paramètre permet de limiter le nombre total de groupes sur tous les nœuds.
La valeur par défaut de ce paramètre est de 256 Ko. Sa taille maximale est 16 Mo.

16-4-4-7. Définition des connexions TCP/IP dans un cluster MySQL▲

TCP/IP est le mécanisme de transport par défaut pour établir des connexions dans le cluster MySQL. Il n'est pas nécessaire de définir une connexion, car il y aura une connexion automatique entre chaque nœud de stockage, entre chaque nœud MySQL et un nœud de stockage, et entre chaque nœud de gestion et les nœuds de stockage.

Il est uniquement nécessaire de définir une connexion que si vous devez modifier les valeurs par défaut de la connexion. Dans ce cas, il est nécessaire de définir au moins NodeId1, NodeId2 et les paramètres modifiés.

Il est aussi possible de modifier les valeurs par défaut en modifiant les valeurs de la section [TCP DEFAULT].

[TCP]NodeId1, [TCP]NodeId2
Pour identifier une connexion entre deux nœuds, il est nécessaire de fournir un identifiant de nœud pour chacun d'entre eux dans NodeId1 et NodeId2.
[TCP]SendBufferMemory
Le transporteur TCP utilise un buffer pour tous les messages avant de les transférer au système d'exploitation. Lorsque le buffer atteint 64 ko, il est envoyé. Le buffer est aussi envoyé lorsque les messages ont été exécutés. Pour gérer les situations temporaires de surcharge, il est possible de définir un sur-buffer. La taille par défaut de ce buffer est 256 ko.
[TCP]SendSignalId
Pour être capable de suivre le diagramme de message distribué, il est nécessaire d'identifier chaque message avec un marqueur. En activant ce paramètre, le marqueur sera aussi transféré sur le réseau. Cette fonctionnalité n'est pas activée par défaut.
[TCP]Checksum
Ce paramètre est aussi un paramètre Y/N (oui/non), qui n'est pas activé par défaut. Lorsqu'il est activé, tous les messages sont munis d'une somme de contrôle avant d'être envoyés au buffer. Les vérifications contre les corruptions sont aussi renforcées.
[TCP]PortNumber
Ceci est le numéro de port à utiliser pour attendre les connexions des autres nœuds. Ce port doit être spécifié dans la section [TCP DEFAULT].
Ce paramètre ne doit plus être utilisé. Utilisez plutôt le paramètre ServerPort sur les nœuds de stockage.
[TCP]ReceiveBufferMemory
Ce paramètre spécifie la taille du buffer utilisé lors de la réception des données dans la socket TCP/IP. Il y a peu de raisons pour modifier ce paramètre, dont la valeur par défaut est 64 ko. Il permettrait uniquement d'économiser de la mémoire.

16-4-4-8. Définition des connexions par mémoire partagée dans un cluster MySQL▲

Les segments de mémoire partagée sont supportés uniquement pour certaines compilations spécifiques du cluster MySQL, avec l'option de configure --with-ndb-shm. Son implémentation va sûrement évoluer. Lorsque vous définissez un segment de mémoire partagée, il est nécessaire de définir au moins NodeId1, NodeId2 et ShmKey. Tous les autres paramètres ont des valeurs par défaut qui fonctionneront dans la plupart des cas.

[SHM]NodeId1, [SHM]NodeId2
Pour identifier une connexion entre deux nœuds, il est nécessaire de fournir l'identité des deux nœuds dans NodeId1 et NodeId2.
[SHM]ShmKey
Lors de la configuration de segments de mémoire partagée, un identifiant est utilisé pour définir de manière unique le segment à utiliser pour les communications. C'est un entier qui n'a pas de valeur par défaut.
[SHM]ShmSize
Chaque connexion a un segment de mémoire où les messages ont été stockés par l'envoyeur, et lus par le lecteur. Ce segment a une taille définie par ce paramètre. Par défaut, il vaut 1 Mo.
[SHM]SendSignalId
Pour être capable de suivre le diagramme de message distribué, il est nécessaire d'identifier chaque message avec un marqueur. En activant ce paramètre, le marqueur sera aussi transféré sur le réseau. Cette fonctionnalité n'est pas activée par défaut.
[SCI]Checksum
Ce paramètre est aussi un paramètre Y/N (oui/non), qui n'est pas activé par défaut. Lorsqu'il est activé, tous les messages sont munis d'une somme de contrôle avant d'être envoyés au buffer. Les vérifications contre les corruptions sont aussi renforcées.

16-4-4-9. Définition d'un transporteur SCI dans un cluster▲

Les transporteurs SCI sont des connexions entre nœuds dans un cluster MySQL, si ce dernier a été compilé avec l'option --with-ndb-sci=/your/path/to/SCI de la commande configure. Le chemin doit pointer sur le dossier qui contient les bibliothèques SCI et leurs fichiers d'entête.

Il est fortement recommandé d'utiliser les transporteurs SCI pour les communications entre les nœuds ndbd. De plus, utiliser les transporteurs SCI signifie que les processus ndbd ne seront jamais inactifs : utilisez ces transporteurs sur des machines qui ont au moins 2 processeurs, dont un est dédié à ndbd. Il faut au moins un processeur par processus ndbd, et un autre pour gérer les activités du système d'exploitation.

[SCI]NodeId1, [SCI]NodeId2
Pour identifier une connexion entre deux nœuds, il est nécessaire de fournir un identifiant de nœud pour chacun d'entre eux dans NodeId1 et NodeId2.
[SCI]Host1SciId0
Identifie le nœud SCI du premier nœud identifié par NodeId1.
[SCI]Host1SciId1
Il est possible de configurer les transporteurs SCI avec reprise sur incident entre deux cartes SCI qui utilisent deux réseaux distincts. Ce paramètre identifie l'identifiant de nœud et la seconde carte à utiliser sur le premier nœud.
[SCI]Host2SciId0
Identifie le nœud SCI du premier nœud identifié par NodeId2.
[SCI]Host2SciId1
Il est possible de configurer les transporteurs SCI avec reprise sur incident entre deux cartes SCI qui utilisent deux réseaux distincts. Ce paramètre identifie l'identifiant de nœud et la seconde carte à utiliser sur le second nœud.
[SCI]SharedBufferSize
Chaque transporteur dispose d'un segment de mémoire partagée entre deux nœuds. Avec ce segment de taille par défaut 1 Mo, la plupart des applications seront satisfaites. Les tailles inférieures (vers 256 ko) posent des problèmes pour les insertions simultanées. Si le buffer est trop petit, il peut conduire à des crashs de ndbd.
[SCI]SendLimit
Un petit buffer devant le media SCI temporise les messages avant de les envoyer sur le réseau SCI. Par défaut, sa taille est de 8 ko. La plupart des tests de vitesse montrent que l'amélioration de vitesse est la meilleure à 64 ko, mais que 16 ko arrive presque au même résultat : il n'y avait plus de différence mesurable après 8 ko au niveau du Cluster.
[SCI]SendSignalId
Pour être capable de suivre le diagramme de message distribué, il est nécessaire d'identifier chaque message avec un marqueur. En activant ce paramètre, le marqueur sera aussi transféré sur le réseau. Cette fonctionnalité n'est pas activée par défaut.
[SCI]Checksum
Ce paramètre est aussi un paramètre Y/N (oui/non), qui n'est pas activé par défaut. Lorsqu'il est activé, tous les messages sont munis d'une somme de contrôle avant d'être envoyés au buffer. Les vérifications contre les corruptions sont aussi renforcées.

Il y a quatre processus à bien connaître lorsque vous utilisez le cluster MySQL. Nous allons voir leur fonctionnement, et leurs options.

16-5-1. 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 trois choses :

son propre numéro d'identifiant de nœud 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.

L'identifiant peut être omis en MySQL version 4.1.5 et plus récent, car les identifiants de nœuds sont dynamiquement alloués.

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".

Sélectionnez

shell> mysqld --ndb-connectstring=ndb_mgmd.mysql.com:2200

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

Avec cette configuration, le serveur MySQL sera partie prenante du cluster MySQL, et accédera à la liste complète de tous les nœuds du cluster ainsi que leur statut. Il va se connecter à tous les nœuds de stockage, et sera capable d'utiliser chacun d'entre eux comme coordinateur de transactions, ainsi que pour accéder aux données.

16-5-2. ndbd, le processus de stockage du cluster▲

ndbd est le processus qui gère les données dans les tables basées sur le moteur NDB Cluster. C'est ce processus qui contient la logique de gestion des transactions distribuées, la restauration des nœuds, la pose des jalons sur le disque, la sauvegarde en ligne, et de nombreuses autres fonctionnalités.

Dans un cluster, il y a un groupe de processus ndbd qui coopèrent pour gérer les données. Ces processus peuvent s'exécuter sur la même machine ou sur des ordinateurs différents, de manière complètement configurable.

Avant MySQL version 4.1.5, le processus ndbd se lançait dans un dossier différent. La raison à cela est que ndbd génère son propre jeu de log dans le dossier de démarrage.

Depuis MySQL 4.1.5, cela a été modifié pour que les fichiers soient placés dans un dossier spécifié par DataDir dans le fichier de configuration. ndbd peut maintenant être lancé depuis n'importe où.

Ces fichiers de logs sont les suivants (le 2 est l'identifiant de nœud).

ndb_2_error.log (anciennement error.log en version 4.1.3) est le fichier qui contient les informations sur tous les plantages que ndbd a rencontrés, et un message d'erreur court ainsi qu'une référence vers le fichier de trace pour le dernier crash. Une telle ligne peut être :
Sélectionnez
```
Date/Time: Saturday 31 January 2004 - 00:20:01
Type of error: error
Message: Internal program error (failed ndbrequire)
Fault ID: 2341
Problem data: DbtupFixAlloc.cpp
Object of reference: DBTUP (Line: 173)
ProgramName: NDB Kernel
ProcessID: 14909
TraceFile: ndb_2_trace.log.2
***EOM***
```
ndb_2_trace.log.1 (anciennement NDB_TraceFile_1.trace en version 4.1.3) est un fichier de trace, décrivant exactement ce qui est arrivé avant l'erreur. Cette information est utile pour l'équipe d'administration du cluster MySQL. Les informations de ce fichier sont décrites dans la section MySQL Cluster Troubleshooting. Le nombre de fichiers de trace est configurable, de manière à maîtriser l'écrasement des anciens fichiers par les nouveaux. 1, dans ce contexte, est le numéro du fichier de trace.
ndb_2_trace.log.next (anciennement NextTraceFileNo.log en version 4.1.3) est le fichier qui garde trace du prochain numéro de fichier de trace.
ndb_2_out.log est le fichier qui contient les données affichées par le processus ndbd. 2, dans ce contexte, est l'identifiant de nœud. Ce fichier n'existe que si ndbd est lancé en mode démon, ce qui est le défaut en 4.1.5; anciennement node2.out en version 4.1.3)
ndb_2.pid est le fichier qui contient l'identifiant de processus lorsque ndbd est lancé en mode démon (c'est le comportement par défaut depuis la version 4.1.5 et s'appelait node2.pid en version 4.1.3). Il fonctionne aussi comme un verrou, pour éviter de lancer des nœuds avec le même identifiant.
ndb_2_signal.log (anciennement Signal.log en version 4.1.3) est le fichier qui ne sert que pour les versions de débogage de ndbd : il est alors possible de suivre les messages entrants, sortants et internes dans le processus ndbd.

Il est recommandé de ne pas utiliser de dossier monté en NFS, car dans certains environnements, il y a des problèmes de verrouillage sur le fichier de PID, même si le processus s'est arrêté.

De même, lorsque vous lancez le processus ndbd, il peut être nécessaire de spécifier le nom d'hôte du serveur de gestion ainsi que son port. Optionnellement, il faut aussi ajouter le numéro d'identification de nœud. Encore une fois, il y a trois façons de spécifier ces informations. Soit une chaîne de connexion qui doit être stockée dans le fichier Ndb.cfg, et ce fichier doit être stocké dans le dossier de démarrage de ndbd. La seconde option est de configurer la variable d'environnement NDB_CONNECTSTRING avant le démarrage du processus. La troisième option est d'utiliser la ligne de commande et l'option ci-dessous. Voyez les sections précédentes pour connaître le format exact de la chaîne.

Sélectionnez

shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:2200"

Lorsque ndbd se lance, il va lancer en fait deux processus. Le processus de lancement s'appelle « angel » et sa seule tâche est de surveiller la fin du processus d'exécution, et de relancer le processus ndbd s'il est configuré pour cela. Par conséquent, si vous tentez de terminer ndbd avec la commande kill d'Unix, il sera nécessaire de terminer les deux processus. Une solution plus élégante pour gérer la terminaison des processus ndbd est d'utiliser le client de gestion et d'arrêter les processus depuis ce client.

Le processus d'exécution utilise un thread pour toutes ses activités de lecture, écriture et analyse des données, ainsi que pour ses autres activités. Ce thread est conçu pour être asynchrone, et gérer facilement des milliers d'actions simultanées. En plus, il y a un garde-fou qui supervise le thread d'exécution, pour s'assurer que ce dernier ne se bloque pas dans une boucle infinie ou dans un autre problème du même genre. Il y a un pool de thread qui assurent les entrées/sorties. Chaque thread gère un fichier. En plus, d'autres threads peuvent être utilisés pour les activités de transport du processus ndbd. Par conséquent, un processus qui effectue un grand nombre d'activités verra le processus ndbd utiliser deux processeurs, s'il en a la possibilité. Sur une machine avec de nombreux processeurs, il est recommandé d'utiliser plusieurs processus ndbd, qui seront configurés pour représenter différents groupes de nœuds.

16-5-3. ndb_mgmd, le serveur de gestion▲

Le serveur de gestion est le processus qui lit le fichier de configuration du cluster, et distribue cette information à tous les nœuds qui le demandent. 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.

Depuis MySQL version 4.1.5, il n'est plus nécessaire de spécifier une chaîne de connexion lors du démarrage du serveur. Si vous utilisez plusieurs serveurs de gestion, une chaîne de connexion doit être fournie, et tous les nœuds du cluster doivent explicitement spécifier leur identifiant.

Les fichiers suivants sont créés ou utilisés par ndb_mgmd dans son dossier de démarrage de ndb_mgmd. Depuis MySQL version 4.1.5, les fichiers de logs et de PID seront placés dans le dossier de données DataDir spécifié dans le fichier de configuration :

config.ini est le fichier de configuration du cluster. Il est créé par l'utilisateur et lu par le serveur de gestion. Comment écrire ce fichier est décrit dans la section Section 16.4, « Configuration de MySQL Cluster »Configuration de MySQL Cluster ;
ndb_1_cluster.log (anciennement cluster.log en version 4.1.3) 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 nœuds, les démarrages de nœuds, les niveaux d'utilisation de mémoire, etc. Les événements rapportés sont décrits dans la section Section 16.6, « Administration de MySQL Cluster »Administration de MySQL Cluster ;
ndb_1_out.log (anciennement node1.out en version 4.1.3) 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 nœud ;
ndb_1.pid (anciennement node1.pid en version 4.1.3) 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 nœud ;
ndb_1_cluster.log.1 (anciennement cluster.log.1 en version 4.1.3), lorsque le log de cluster dépasse un million d'octets, alors le fichier de logs prend le nom indiqué ici, où 1 est le nombre de fichiers de logs : si 1, 2 et 3 existent déjà, le suivant sera le numéro 4.

16-5-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 tâches d'administration automatisées.

Lorsque vous lancez le client de gestion, il est nécessaire d'indiquer le nom d'hôte et le port du serveur de gestion, comme dans l'exemple ci-dessous. Par défaut, c'est l'hôte local et le port 2200.

Sélectionnez

shell> ndb_mgm localhost 2200

16-5-5. Options des commandes pour le cluster MySQL▲

16-5-5-1. Options de cluster de mysqld▲

--ndbcluster
Si le binaire supporte le moteur de table NDB Cluster, le comportement par défaut est de désactiver son support. Vous pouvez changer ce comportement avec cette option. Utiliser le moteur NDB Cluster est obligatoire pour pouvoir utiliser MySQL Cluster.
--skip-ndbcluster
Désactive le moteur de table NDB Cluster. C'est le comportement par défaut pour les applications où il est inclus. Cette option peut s'appliquer uniquement si le serveur a été configuré pour utiliser le moteur de table NDB Cluster.
--ndb-connectstring=connect_string
Lorsque de l'utilisation du moteur de table NDB, il est possible de désigner le serveur de gestion qui distribue les configurations du cluster en lui assignant une chaîne de connexion.

16-5-5-2. Options de la commande ndbd▲

-?, --usage
Ces options ne font qu'afficher l'aide du programme.
-c connect_string, --connect-string connect_string
Pour ndbd, il est aussi possible de spécifier la chaîne de connexion au serveur de commande, sous forme d'option.
Sélectionnez
```
shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:2200"
```
-d, --daemon
Indique à ndbd qu'il doit s'exécuter comme démon. Depuis MySQL version 4.1.5, c'est le comportement par défaut.
--nodaemon
Indique à ndbd qu'il ne doit pas se lancer comme un démon. C'est pratique lors du débogage de ndbd et que vous voulez avoir l'affichage des résultats du programme.
--initial
Demande à ndbd de faire un démarrage initial. Un démarrage initial efface tous les fichiers créés par d'anciens ndbd durant la restauration. Il va aussi créer le fichier de logs de restauration, ce qui peut prendre beaucoup de temps sur certains systèmes d'exploitation.
Un démarrage initial ne sert qu'au tout premier démarrage du processus ndbd. Il supprime tous les fichiers du système de fichiers, et crée tous les fichiers de logs REDO. Lorsque vous faites une mise à jour logicielle qui modifie le contenu de ces fichiers, il est aussi nécessaire d'utiliser cette option au redémarrage de ndbd. Enfin, cette option peut être utile en dernier recours, si votre système n'arrive pas à redémarrer. Dans ce cas, soyez conscients que détruire le contenu du système de fichiers signifie que ce nœud ne peut plus être utilisé pour restaurer des données.
Cette option n'affecte pas les fichiers de sauvegarde créés.
L'ancienne fonctionnalité représentée par -i pour cette option a été supprimée pour s'assurer qu'elle n'est pas confondue avec celle-ci par mégarde.
--nostart
Indique à ndbd de ne pas démarrer automatiquement. ndbd va se connecter au serveur de gestion, obtiendra le fichier de configuration, et initialisera les communications avec les nœuds. Mais il ne va pas lancer le moteur d'exécution jusqu'à ce qu'il en reçoive l'ordre manuel du serveur de gestion. Le serveur de gestion peut émettre cette commande sur ordre du client de gestion.
-v, --version
Affiche le numéro de version du processus ndbd. Le numéro de version est celui du cluster MySQL. Il est important, car au moment du lancement du cluster, MySQL vérifie si les versions des serveurs des nœuds peuvent cohabiter dans le cluster. Il est aussi important durant les mises à jour logicielles du cluster (voyez la section Software Upgrade of MySQL Cluster).
--debug=options
Cette option peut être utilisée avec les versions compilées en mode débogage. Elle sert à activer l'affichage des appels de débogage, de la même manière que pour mysqld.
-? --usage
Affiche une description rapide des options disponibles.

16-5-5-3. Options de commande pour ndb_mgmd▲

-?, --usage
Ces options font afficher l'aide du programme.
-c filename, --config-file=filename
Indique au serveur de gestion quel fichier de configuration utiliser. Cette option est obligatoire. Le nom par défaut du fichier est config.ini.
-d, --daemon
Indique au client ndb_mgmd de se lancer sous forme de démon. C'est le comportement par défaut.
-nodaemon
Indique au serveur de gestion de ne pas se lancer comme un démon.
-v, --version
Affiche le numéro de version du serveur de gestion. Le numéro de version est celui du cluster MySQL. Le serveur de gestion peut s'assurer que seules les versions compatibles avec lui sont acceptées et utilisées dans le cluster.
--debug=options
Cette option ne peut être utilisée que dans les versions compilées en mode débogage. Elle est utilisée pour afficher plus d'informations de fonctionnement et accepter les appels de fonctions de débogages de mysqld.

16-5-5-4. Options de commande pour ndb_mgm▲

-?, --usage
Ces options ne font qu'afficher l'aide du programme.
[host_name [port_num]]
Pour lancer le client de gestion, il est nécessaire de spécifier où le serveur de gestion réside. Cela signifie qu'il faut spécifier le nom d'hôte et le port de communication. Par défaut, l'hôte est localhost et le port par défaut est 2200.
--try-reconnect=number
Si la connexion au serveur de gestion se perd, il est possible de spécifier le nombre de tentatives avant de conclure à une erreur. Par défaut, le client va réessayer toutes les 5 secondes jusqu'à ce qu'il réussisse.

Gérer un cluster MySQL implique différentes opérations. La première est celle de configurer et de démarrer le cluster MySQL : elle est couverte par les sections Section 16.4, « Configuration de MySQL Cluster »Configuration de MySQL Cluster et Section 16.5, « Serveur de gestion du cluster MySQL »Serveur de gestion du cluster MySQL. Cette section couvre la gestion d'un cluster MySQL en fonctionnement.

Il y a essentiellement deux moyens pour gérer activement un cluster MySQL en fonctionnement. La première est l'utilisation des commandes dans le client de gestion, qui surveille le statut du cluster, les niveaux de logs, les sauvegardes en cours et les nœuds qui peuvent être arrêtés ou relancés. La seconde méthode utilise le résultat du log du cluster. Le log du cluster est envoyé dans le fichier ndb_2_cluster.log dans le dossier DataDir du serveur de gestion. Le log du cluster contient les rapports d'événements du moteur ndbd et de ses processus dans le cluster. Il est possible aussi d'envoyer le log dans le log système Unix.

16-6-1. 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 nœud de base de données (i.e. 21) ou le mot-clé ALL qui indique que la commande doit être appliquée à tous les nœuds 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 nœud de base de données identifié par <id>, ou bien tous les nœuds.
<id> STOP
Stoppe le nœud de base de données identifié par <id>, ou bien tous les nœuds.
<id> RESTART [-N] [-I]
Relance le nœud de base de données identifié par <id>, ou bien tous les nœuds.
<id> STATUS
Affiche les informations de statut du nœud de base de données identifié par <id> (ou de tous les nœuds avec ALL).
ENTER SINGLE USER MODE <id>
Active le mode d'utilisateur unique, où seule l'API avec le nœud <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 nœuds du cluster, hormis les serveurs MySQL, puis s'arrête.

Les commandes des logs d'événements sont listées dans la prochaine section, et les commandes de sauvegarde sont données dans une section séparée.

16-6-2. Rapport d'événements générés par le cluster MySQL▲

Le cluster MySQL a deux logs d'événements : le log de cluster et le log de nœuds.

Le log de cluster est un log pour le cluster entier, et il peut avoir différentes destinations (fichiers, console du serveur de gestion, ou log système).
Le log de nœuds est un log local à chaque nœud, et il est envoyé vers la console. Les deux logs peuvent être configurés pour recevoir des sous-ensembles de tous les événements.

Note : le log du cluster est le log recommandé. Le log de nœuds ne sert que pour le développement d'application ou le débogage.

Chaque événement a les propriétés suivantes :

Catégorie (STARTUP, SHUTDOWN, STATISTICS, CHECKPOINT, NODERESTART, CONNECTION, ERROR, INFO) ;
Priorité (1-15 où 1 est le plus important, et 15 le moins important) ;
Sévérité (ALERT, CRITICAL, ERROR, WARNING, INFO, DEBUG).

Les deux logs (celui du cluster et celui du nœud) peuvent être filtrés en fonction de ces propriétés.

16-6-2-1. Historique des commandes de gestion▲

Les commandes suivantes sont liées au log du cluster :

CLUSTERLOG ON
Activation du log du cluster
CLUSTERLOG OFF
Désactivation du log du cluster.
CLUSTERLOG INFO
Informations sur la configuration du log.
<id> CLUSTERLOG <category>=<threshold>
Enregistre les catégories d'événements ayant une priorité inférieure ou égale au seuil indiqué, dans le log du cluster.
CLUSTERLOG FILTER <severity>
Active/désactive l'enregistrement des types de sévérités indiquées.

La table suivante décrit les configurations par défaut pour tous les nœuds de bases de données dans le cluster. Si un événement a une priorité dont la valeur est inférieure ou égale à seuil de priorité, il est alors enregistré dans le log du cluster.

Notez que les événements sont rapportés pour chaque nœud de base de données, et que les seuils peuvent être différents sur chaque nœud.

Catégorie	seuil par défaut (toutes les bases)
STARTUP	7
SHUTDOWN	7
STATISTICS	7
CHECKPOINT	7
NODERESTART	7
CONNECTION	7
ERROR	15
INFO	7

Un seuil permet de filtrer les événements par catégorie. Par exemple, un événement STARTUP avec une priorité de 3 n'est jamais émis à moins que le seuil de STARTUP ne soit changé à 3 ou plus bas. Seuls les événements avec des priorités de 3 ou plus bas sont émis si le seuil est de 3. Les sévérités d'événements correspondent au niveau du log système d'UNIX. Ce sont :

1	ALERT	Un problème qui doit être corrigé immédiatement, comme une base de données corrompue
2	CRITICAL	Problèmes critiques, comme une erreur de volume ou un manque de ressources
3	ERROR	Problèmes qui doivent être corrigés, comme un problème de configuration
4	WARNING	Problèmes qui ne sont pas des erreurs, mais requièrent un traitement
5	INFO	Message d'information
6	DEBUG	Messages pour le développement de NDB Cluster

Les niveaux syslog de LOG_EMERG et LOG_NOTICE ne sont pas utilisés.

Les sévérités d'événements peuvent être activées ou pas. Si la sévérité est active, alors tous les événements avec une priorité inférieure ou égale au seuil seront enregistrés. Si la sévérité est éteinte, alors aucun événement de cette sévérité ne sera enregistré.

Les commandes suivantes sont liées au log du nœud :

<id> LOGLEVEL <levelnumber> Active le niveau de log pour le processus de base de données id, avec le niveau <levelnumber>.

16-6-2-2. Événements▲

Tous les événements rapportés sont listés ici.

Événements	Catégorie	Priorité	Sévérité	Description
DB nodes connected	CONNECTION	8	INFO
DB nodes disconnected	CONNECTION	8	INFO
Communication closed	CONNECTION	8	INFO	Connexion aux nœuds API & DB fermée
Communication opened	CONNECTION	8	INFO	Connexion aux nœuds API & DB fermée
Global checkpoint started	CHECKPOINT	9	INFO	Début de GCP, i.e., le log REDO est écrit sur le disque
Global checkpoint completed	CHECKPOINT	10	INFO	GCP terminé
Local checkpoint started	CHECKPOINT	7	INFO	Début d'une vérification de jalon local, i.e., les données sont écrites sur le disque. LCP Id et GCI Id
Local checkpoint completed	CHECKPOINT	8	INFO	LCP terminé
LCP stopped in calc keep GCI	CHECKPOINT	0	ALERT	LCP arrêté !
Local checkpoint fragment completed	CHECKPOINT	11	INFO	Un LCP sur un fragment a été terminé
Report undo log blocked	CHECKPOINT	7	INFO	Le log d'annulation est bloqué, car le buffer est presque plein
DB node start phases initiated	STARTUP	1	INFO	NDB Cluster démarre
DB node all start phases completed	STARTUP	1	INFO	NDB Cluster démarré
Internal start signal received STTORRY	STARTUP	15	INFO	Signal interne pour bloquer la réception après la fin du redémarrage
DB node start phase X completed	STARTUP	4	INFO	La phase de démarrage est finie
Node has been successfully included into the cluster	STARTUP	3	INFO	Le nœud président, le nœud courant et l'identifiant dynamique sont affichés
Node has been refused to be included into the cluster	STARTUP	8	INFO
DB node neighbours	STARTUP	8	INFO	Affichage des nœuds voisins à gauche et à droite
DB node shutdown initiated	STARTUP	1	INFO
DB node shutdown aborted	STARTUP	1	INFO
New REDO log started	STARTUP	10	INFO	GCI garde X, dernier jalon accessible GCI Y
New log started	STARTUP	10	INFO	Log termine X, démarre MB Y, stoppe MB Z
Undo records executed	STARTUP	15	INFO
Completed copying of dictionary information	NODERESTART	8	INFO
Completed copying distribution information	NODERESTART	8	INFO
Starting to copy fragments	NODERESTART	8	INFO
Completed copying a fragment	NODERESTART	10	INFO
Completed copying all fragments	NODERESTART	8	INFO
Node failure phase completed	NODERESTART	8	ALERT	Indique un échec de nœud
Node has failed, node state was X	NODERESTART	8	ALERT	Indique qu'un nœud a échoué
Report whether an arbitrator is found or not	NODERESTART	6	INFO	7 résultats différents Président relance le thread d'arbitrage [state=X] Préparation de l'arbitrage, nœud X [ticket=Y] Reçoit l'arbitrage, nœud X [ticket=Y] Démarre l'arbitrage X [ticket=Y] Perte de l'arbitrage, nœud X - echec de traitement [state=Y] Perte de l'arbitrage, nœud X - fin de traitement [state=Y] Perte de l'arbitrage, nœud X <error msg>[state=Y]
Report arbitrator results	NODERESTART	2	ALERT	8 résultats différents Arbitrage perdu - moins de la moitié des nœuds dispo Arbitrage gagné - majorité du groupe de nœuds Arbitrage perdu - plus de groupe de nœuds Partage du réseau - arbitrage demandé Arbitrage gagné - réponse positive du nœud X Arbitrage perçus - réponse négative du nœud X Partage du réseau - pas d'arbitre disponible Partage du réseau - par d'arbitre configuré
GCP take over started	NODERESTART	7	INFO
GCP take over completed	NODERESTART	7	INFO
LCP take over started	NODERESTART	7	INFO
LCP take completed (state = X)	NODERESTART	7	INFO
Report transaction statistics	STATISTICS	8	INFO	nombre de transactions, archivages, lectures, lectures simples, écritures, opérations simultanées, attributs, annulations
Report operations	STATISTICS	8	INFO	nombre d'opérations
Report table create	STATISTICS	7	INFO
Report job scheduling statistics	STATISTICS	9	INFO	Statistiques internes de programmation de tâches
Sent # of bytes	STATISTICS	9	INFO	Moyenne de nombre d'octets envoyés au nœud X
Received # of bytes	STATISTICS	9	INFO	Moyenne de nombre d'octets reçus au nœud X
Memory usage	STATISTICS	5	INFO	Uitlisation de la mémoire pour les données et les index(80 %, 90 % et 100 %)
Transporter errors	ERROR	2	ERROR
Transporter warnings	ERROR	8	WARNING
Missed heartbeats	ERROR	8	WARNING	Le nœud X a raté une pulsation # Y
Dead due to missed heartbeat	ERROR	8	ALERT	Le nœud X est déclaré mort à cause des pulsations manquées
General warning events	ERROR	2	WARNING
Sent heartbeat	INFO	12	INFO	Pulsation envoyée au nœud X
Create log bytes	INFO	11	INFO	Partie de log, fichier de logs, taille
General info events	INFO	2	INFO

Un événement a le format suivant dans le log :

Sélectionnez

<date & time in GMT> [<any string>] <event severity> -- <log message>

09:19:30 2003-04-24 [NDB] INFO -- Node 4 Start phase 4 completed

16-6-3. Utilisateur unique du cluster▲

Le mode d'utilisateur unique permet à l'administrateur de restreindre l'accès au système de base de données à une seule application (un nœud API). Lorsque vous passez en mode utilisateur unique, toutes les connexions aux nœuds d'API seront refermées et aucune transaction ne sera autorisée. Toutes les transactions en cours sont annulées.

Lorsque le cluster entre en mode d'utilisateur unique (utilisez la commande de statut pour voir si l'état est activé), seul le nœud autorisé dispose d'un accès à la base de données.

Exemple :

Sélectionnez

ENTER SINGLE USER MODE 5

Après avoir exécuté cette commande, et après que le cluster est entré en mode d'utilisateur unique, le nœud d'API d'identifiant 5 devient le seul utilisateur du cluster.

Le nœud spécifié dans la commande ci-dessus doit être un nœud MySQL. Toute tentative de spécifier un autre type de nœud sera rejetée.

Note : si le nœud avec l'identifiant 5 est exécuté avec le mode ENTER SINGLE USER MODE 5, toutes les transactions du nœud 5 seront annulées, les connexions fermées et le serveur devra redémarrer.

La commande EXIT SINGLE USER MODE fait passer le cluster de mode « single user mode » à « started ». Les serveurs MySQL en attente de connexion seront autorisés à se connecter. Le serveur identifié comme utilisateur unique sera autorisé à continuer durant et après la phase de transition.

Exemple :

Sélectionnez

EXIT SINGLE USER MODE

La meilleure pratique dans le cas des incidents de nœuds en mode d'utilisateur unique est de :

Finir toutes les transactions d'utilisateur unique ;
Quitter le mode d'utilisateur unique ;
Redémarrer les nœuds de bases de données.

Ou redémarrer les nœuds de bases avant de passer en mode utilisateur unique.

16-6-4. Sauvegarde en ligne de MySQL Cluster▲

Cette section décrit comment créer une sauvegarde et restaurer ultérieurement une base de données.

16-6-4-1. Sauvegarde du cluster▲

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

Les métadonnées (quelles tables existent, etc.) ;
Les lignes des tables(les données) ;
Un historique des transactions archivées.

Chaque partie est stockée sur tous les nœuds qui participent à la sauvegarde.

Durant une sauvegarde, chaque nœud sauve ses 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étadonnées ;
BACKUP-<BackupId>-0.<NodeId>.data
Le fichier de données qui contient les lignes des tables ;
BACKUP-<BackupId>.<NodeId>.log
Le fichier de logs, qui contient les transactions archivées.

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

Meta data
Les métadonnées sont constituées des définitions de table. Tous les nœuds 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 appartiennent les lignes. Après un groupe de lignes, il y a pied-de-page qui contient une somme de contrôle. Différents nœuds sauvent différents fragments durant la sauvegarde.
Committed log
L'historique contient les transactions archivées, effectuées durant la sauvegarde. Seules les transactions impliquant les tables stockées sur le nœud sont stockées dans le log. Les différents nœuds de la sauvegarde sauvent différents logs, car ils abritent différents fragments de bases de données.

16-6-4-2. Utilisation du serveur de gestion pour une sauvegarde de cluster▲

Avant de lancer la sauvegarde, assurez-vous que le cluster est correctement configuré pour les sauvegardes.

Lancez le serveur de gestion.
Exécutez la commande START BACKUP.
Le serveur de gestion vous indiquera « Start of backup ordered ». Cela signifie que le serveur de gestion a envoyé la requête au cluster, mais qu'il n'a pas encore reçu de réponse.
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.
Le serveur de gestion va indiquer que la sauvegarde est finie avec le message « Backup <BackupId> completed ».

Utilisation du serveur pour annuler une sauvegarde :

Lancez le serveur de gestion ;
Exécutez la commande ABORT BACKUP <BACKUPID>. Le numéro <BackupId> est l'identifiant de la sauvegarde, qui est inclus 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) ;
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 ;
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.

Notez que s'il n'y a pas de sauvegarde en cours avec l'identifiant <BackupId> lors de l'annulation, le serveur de gestion ne répondra rien du tout. Cependant, une ligne sera enregistrée dans le log du cluster mentionnant « invalid ».

16-6-4-3. Comment restaurer une sauvegarde du cluster▲

Le programme de restauration est une commande distincte. Il lit les fichiers de sauvegarde créés, et insère les informations dans la base. Le programme de restauration doit être exécuté pour chaque fichier de sauvegarde, c'est-à-dire aussi souvent qu'il y a de nœuds dans le cluster au moment de la création de la sauvegarde.

La première fois que vous exécutez le programme de restauration, vous devez aussi restaurer les métadonnées, c'est-à-dire créer les tables. Le programme de restauration sert d'API avec le cluster, et il a donc besoin d'une connexion libre pour ce faire. Vous pouvez le vérifier avec la commande SHOW de ndb_mgm. De la même manière que pour les autres nœuds API, c'est-à-dire mysqld,le fichier Ndb.cfg, la variable d'environnement NDB_CONNECTSTRING ou l'option de démarrage -c <connectstring> sert à situer le serveur de gestion. Les fichiers de sauvegarde doivent être présents dans le dossier indiqué comme argument du programme. La sauvegarde peut être restaurée vers une base ayant une configuration différente de celle qui a créé la sauvegarde. Par exemple, la sauvegarde 12, créée avec deux nœuds de bases d'identifiants 2 et 3, peut être restaurée sur un cluster de 4 nœuds. Le programme doit alors être exécuté 2 fois : une fois pour chaque nœud du cluster où la sauvegarde a été faite, tel que décrit ci-dessous.

Note : pour une restauration rapide, les données peuvent être relues en parallèle, tant qu'il y a suffisamment de connexions API libres. Notez que les fichiers de données doivent toujours être appliqués avant les logs.

Note : le cluster doit toujours être vide lors du démarrage d'une restauration.

16-6-4-4. Configuration pour la sauvegarde du Cluster▲

Il y a quatre paramètres de configuration pour la sauvegarde :

BackupDataBufferSize
La quantité de mémoire utilisée pour les buffers avant que les données soient écrites sur le disque ;
BackupLogBufferSize
La quantité de mémoire utilisée pour les buffers de logs, avant qu'ils ne soient écrits sur le disque ;
BackupMemory
La quantité totale de mémoire allouée pour effectuer les sauvegardes. Cela doit être la somme des deux options précédentes ;
BackupWriteSize
La taille des blocs écrits sur le disque. Cela s'applique aussi bien aux buffers de données qu'aux buffers de log.

16-6-4-5. Résolution de problèmes avec la sauvegarde du cluster▲

Si un code d'erreur est retourné lors de la sauvegarde, alors vérifiez s'il y a assez de mémoire allouée pour la sauvegarde (i.e. les paramètres de configuration). Vérifiez aussi s'il y a assez d'espace sur le disque pour tout accueillir.

Bien avant de concevoir le cluster NDB en 1996, il est apparu que l'un des problèmes majeurs dans l'architecture d'une base de données parallèle est la communication entre les nœuds via un réseau. Par conséquent, dès le début, le cluster NBD a été conçu pour supporter le concept de transporteur, et pour en supporter différentes sortes.

Actuellement, le code de base inclut 4 transporteurs différents, dont 3 d'entre eux sont déjà fonctionnels. La majorité des utilisateurs exploitent TCP/IP aujourd'hui, via Ethernet, car ces technologies sont disponibles sur toutes les machines. C'est aussi le transporteur le mieux testé du MySQL Cluster.

Chez MySQL, nous travaillons fort pour nous assurer que les communications entre les processus ndbd sont faites avec des paquets aussi gros que possible, car cela profitera à tous les médias de communication : tous les modes de transports gagnent à envoyer des messages de grande taille par rapport à des messages de petite taille.

Pour les utilisateurs qui recherchent les performances absolues, il est aussi possible d'utiliser des interconnexions de cluster pour améliorer encore les performances. Il y a deux moyens pour cela, soit en utilisant un transporteur qui a été conçu pour cela, soit en utilisant des sockets qui évitent le recours aux piles TCP/IP.

Nous avons fait des expériences avec les variantes de ces techniques, et avec la technologie SCI, développée par Dolphin (www.dolphinics.no).

16-7-1. Configurer le cluster MySQL avec les sockets SCI▲

Dans cette section, nous allons vous montrer comment utiliser un cluster TCP/IP normal avec les sockets SCI. Le prérequis pour cela est que les machines doivent être capables de communiquer avec des cartes SCI. Cette documentation est basée sur les sockets SCI version 2.3.0, du 1^er octobre 2004.

Pour utiliser les sockets SCI, vous pouvez utiliser n'importe quelle version du cluster MySQL. Les tests ont été faits sur la version 4.1.6. Aucune compilation particulière n'est nécessaire, car il utilise les appels normaux aux sockets, ce qui est la configuration de MySQL Cluster. Les sockets SCI ne sont supportées que sur les noyaux Linux 2.4 et 2.6 pour le moment. Les transporteurs SCI fonctionnent sur d'autres systèmes d'exploitation, même si seul Linux 2.4 a été vérifié.

Il y a essentiellement 4 choses nécessaires pour activer les sockets SCI. La première est de compiler les bibliothèques de sockets SCI. La seconde est d'installer les bibliothèques SCI dans le noyau. La troisième est d'installer les fichiers de configuration. Enfin, la bibliothèque SCI du noyau doit être activée pour toute la machine, ou pour le shell d'où le cluster MySQL est lancé. Ce processus doit être répété pour chaque machine du cluster qui utilisera les sockets SCI pour communiquer.

Deux paquets doivent être installés pour faire fonctionner les sockets SCI. Le premier paquet compile les bibliothèques avec lesquelles les bibliothèques SCI sont compilées. Actuellement, la distribution est uniquement au format code source.

Les dernières versions de ces paquets sont actuellement disponibles à :

Sélectionnez

http://www.dolphinics.no/support/downloads.html

Sélectionnez

http://www.dolphinics.no/ftp/source/DIS_GPL_2_5_0_SEP_10_2004.tar.gz
http://www.dolphinics.no/ftp/source/SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz

La prochaine étape est de décompresser ces dossiers. Les sockets SCI sont décompressées sous le code DIS. Puis, le code de base est compilé. L'exemple ci-dessous montre les commandes utilisées sur Linux/x86 pour ce faire.

Sélectionnez

shell> tar xzf DIS_GPL_2_5_0_SEP_10_2004.tar.gz
shell> cd DIS_GPL_2_5_0_SEP_10_2004/src/
shell> tar xzf ../../SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz
shell> cd ../adm/bin/Linux_pkgs
shell> ./make_PSB_66_release

Si la compilation se passe sur une machine Opteron, et doit utiliser l'extension 64 bits, alors utilisez make_PSB_66_X86_64_release à la place. Si la compilation a lieu sur Itanium, utilisez make_PSB_66_IA64_release. Les variantes X86-64 devraient fonctionner pour les architectures Intel EM64T, mais aucun test n'est connu pour cela.

Après avoir compilé le code de base, il est placé dans une archive compressée. Il est temps d'installer le paquet au bon endroit. Dans cet exemple, nous allons placer l'installation dans le dossier /opt/DIS. Ces actions vous imposeront de vous identifier comme super-utilisateur.

Sélectionnez

shell> cp DIS_Linux_2.4.20-8_181004.tar.gz /opt/
shell> cd /opt
shell> tar xzf DIS_Linux_2.4.20-8_181004.tar.gz
shell> mv DIS_Linux_2.4.20-8_181004 DIS

Maintenant que les bibliothèques et les binaires sont en place, nous devons nous assurer que les cartes SCI reçoivent les bons identifiants de nœuds dans l'espace SCI. Comme SCI est un élément réseau, nous devons commencer par décider de la structure du réseau.

Il y a trois types de structure de réseau : la première est un simple anneau unidimensionnel, le second utilise les hubs SCI, avec un anneau par hub, et finalement, il y a des tores 2D et 3D. Chaque type a sa technique pour attribuer les identifiants.

Un anneau simple utilise des identifiants espacés de 4 :

Sélectionnez

4, 8, 12, …

La deuxième méthode utilise des hubs. Le hub SCI a 8 ports. Sur chaque port, il est possible de placer un anneau. Il est nécessaire de s'assurer que les anneaux des hubs utilisent des espaces d'identifiants différents. Le premier port utilisera les identifiants inférieurs à 64, et les 64 identifiants suivants seront attribués au prochain port, etc.

Sélectionnez

4,8, 12, …, 60  Anneau du premier port
68, 72, …, 124 Anneau du deuxième port
132, 136, …, 188 Anneau du troisième port
…
452, 456, …, 508 Anneau du huitième port

Les structures de réseaux en tore 2D/3D prennent en compte la position de chaque nœud dans chaque dimension. La première dimension est incrémentée de 4, la deuxième de 64 et la troisième de 1024. Regardez dans le dauphin pour plus d'informations dessus.

Durant nos tests, nous avons utilisé des hubs. La majorité des très gros clusters utilisent des installations à Tore 2D/3D. La fonctionnalité supplémentaire que permettent les hubs est qu'avec des doubles cartes SCI, nous pouvons facilement construire un réseau redondant, où les erreurs de réseau sont aussitôt reprises en 100 microsecondes. Cette fonctionnalité est supportée par le transporteur SCI, et est actuellement en développement pour les sockets SCI.

La reprise sur échec est aussi possible avec les tores 2D/3D, mais elle impose l'envoi de nouveaux index de routages à tous les nœuds. Cela prend environ 100 millisecondes et sera probablement acceptable pour les situations de haute disponibilité.

En agençant correctement les nœuds NDB dans l'architecture, il est possible d'utiliser deux hubs pour monter une architecture de 16 ordinateurs interconnectés, sans aucun point d'interruption. Avec 32 ordinateurs et 2 hubs, il est possible de configurer le cluster de telle manière qu'un incident ne perturbera pas plus de 2 nœuds, et dans ce cas, on saura même quelle paire sera touchée. Par conséquent, en plaçant ces serveurs dans des groupes NDB séparés, il est possible de construire un cluster MySQL sécurisé. Nous n'entrerons pas dans les détails de cette architecture, car seuls ceux qui le souhaitent auront la patience de lire ce niveau de détails.

Pour configurer l'identifiant de nœud sur une carte SCI, utilisez l'une des commandes disponibles dans le dossier /opt/DIS/sbin. -c 1 fait référence à la carte SCI, où 1 est son numéro s'il y a une seule carte sur la machine. Dans ce cas, utilisez toujours l'adapteur 0 (avec -a 0). 68 est l'identifiant de nœud choisi comme exemple :

Sélectionnez

shell> ./sciconfig -c 1 -a 0 -n 68

Dans ce cas, nous avons plusieurs cartes SCI dans notre machine, et la seule solution sécuritaire pour savoir quelle carte est dans quel emplacement est d'utiliser la commande suivante :

Sélectionnez

shell> ./sciconfig -c 1 -gsn

Elle vous retournera le numéro de série de la carte, qui peut être trouvée sur son dos. Répétez cette manipulation avec -c 2, etc., en fonction du nombre de cartes que vous avez sur la machine. Vous pourrez ainsi identifier les cartes de la machine.

Maintenant, nous avons installé les bibliothèques et les exécutables. Nous avons aussi configuré les identifiants de nœuds. L'étape d'après est d'effectuer le plan de noms ou d'adresses IP pour les nœuds SCI.

Le fichier de configuration des sockets SCI doit être placé dans le fichier /etc/sci/scisock.conf. Ce fichier contient la carte des noms d'hôtes et leur correspondance avec les nœuds SCI. L'identifiant de nœud SCI correspond avec un autre via la carte SCI. Ci-dessous, voici un fichier de configuration très simple :

Sélectionnez

#host           #nodeId 
alpha           8
beta            12
192.168.10.20   16

Il est aussi possible de limiter cette configuration pour qu'elle ne s'applique qu'à une sous-partie des ports des hôtes. Pour cela, une autre configuration est utilisée, et placée dans /etc/sci/scisock_opt.conf.

Sélectionnez

#-key                        -type        -values
EnablePortsByDefault                  yes
EnablePort                  tcp           2200
DisablePort                 tcp           2201
EnablePortRange             tcp           2202 2219 
DisablePortRange            tcp           2220 2231

Maintenant, nous sommes prêts à installer les pilotes. Nous devons installer d'abord les pilotes bas-niveau, puis les pilotes SCI sockets.

Sélectionnez

shell> cd DIS/sbin/
shell> ./drv-install add PSB66
shell> ./scisocket-install add

Si vous voulez, vous pouvez maintenant tester votre installation en appelant le script qui teste tous les nœuds SCI.

Sélectionnez

shell> cd /opt/DIS/sbin/
shell> ./status.sh

Si vous rencontrez une erreur et que vous devez changer les fichiers de configuration SCI, alors il faudra utiliser le programme ksocketconfig pour adapter les configurations.

Sélectionnez

shell> cd /opt/DIS/util
shell> ./ksocketconfig -f

Pour vérifier que les sockets SCI sont fonctionnels, vous pouvez utiliser le programme latency_bench qui a besoin d'un composant serveur et d'un client qui se connecte au serveur, pour tester les délais : l'activation de SCI est évidente en lisant les délais de latence. Avant d'utiliser ces programmes, vous devrez configurer la variable LD_PRELOAD telle que ci-dessous.

To set up a server use the command

Sélectionnez

shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -server

Pour exécuter le client, utilisez cette commande :

Sélectionnez

shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -client hostname_of_server

Maintenant, la configuration des sockets SCI est complète. Le cluster MySQL est prêt à s'exécuter avec les sockets SCI et le transporteur SCI, documenté dans Section 16.4.4.9, « Définition d'un transporteur SCI dans un cluster »Définition d'un transporteur SCI dans un cluster.

La prochaine étape est de lancer le cluster MysQL. Pour activer l'utilisation des sockets SCI, il est nécessaire de configurer la variable d'environnement LD_PRELOAD avant de lancer ndbd, mysqld et ndb_mgmd. La variable LD_PRELOAD doit pointer sur la bibliothèque du noyau qui supporte les sockets SCI.

Voici un exemple pour lancer ndbd depuis un bash :

Sélectionnez

bash-shell> export LD_PRELOAD=/opt/DIS/lib/libkscisock.so
bash-shell> ndbd

Depuis un environnement tcsh, la même chose se fait avec les commandes suivantes.

Sélectionnez

tcsh-shell> setenv LD_PRELOAD=/opt/DIS/lib/libkscisock.so
tcsh-shell> ndbd

Notez bien que le cluster MySQL ne peut utiliser que les variantes du noyau des sockets SCI.

16-7-2. Mesures de vitesses pour comprendre les impacts sur le cluster▲

Le processus ndbd dispose de nombreuses structures simples qui sont utilisées pour accéder aux données du cluster MySQL. Voici quelques indicateurs de performances pour mesurer les performances des commandes et les effets des interconnexions sur les performances.

Il existe 4 méthodes d'accès :

Accès par clé primaire
C'est un accès simple à une ligne, via sa clé primaire. Dans le cas le plus simple, une seule ligne est lue en même temps. Cela signifie que le coût total des messages TCP/IP et des changements de contexte est pris en charge par cette seule opération. Dans un mode par lots, où les clés primaires sont distribuées par groupe de 32, chaque groupe va partager le coût des messages TCP/IP et les coûts de changement de contexte (si les messages sont destinés à différents nœuds, il faudra construire les messages nécessaires) ;
Accès par clé unique
Les accès par clé unique sont très similaires aux accès par clé primaire, hormis le fait qu'ils sont exécutés sous forme de lecture de l'index, suivi par un accès de clé primaire. Cependant, une seule requête est envoyée par le serveur MySQL, et la lecture de l'index est gérée par le processus ndbd. Par conséquent, ces requêtes gagnent à être réalisées en groupe ;
Analyse complète de table
Lorsqu'aucun index n'existe pour une table, cette dernière est entièrement analysée. C'est une seule requête qui est envoyée au processus ndbd, qui la divise en analyses parallèles dans les nœuds du cluster. Dans les futures versions du cluster, MySQL sera capable de filtrer un peu mieux ces analyses ;
Analyse d'intervalle avec un index ordonné
Lorsqu'un index ordonné est utilisé, il va faire une analyse de la même manière qu'une analyse de table, mais il ne traitera que les lignes qui sont dans l'intervalle indiqué par la requête. Dans les futures versions, une optimisation spéciale aura lieu pour s'assurer que tous les attributs de l'index qui sont liés incluent les attributs de la clé, pour que seule une partie de l'index soit analysé, et non pas analysé en parallèle.

Pour vérifier les performances de base de ces méthodes d'accès, nous avons développé un jeu de tests. Un des tests, testReadPerf, effectue des accès via clé primaire, clé unique, en batch ou non. Les tests mesurent aussi le coût des analyses par intervalles, en effectuant des tests qui retournent une seule ligne, et finalement, des variantes qui utilisent des analyses d'intervalle pour lire des groupes de lignes.

Dans cette manière, il est possible de mesurer le coût d'un accès à une clé, et le coût de l'analyse d'une ligne, puis de mesurer l'impact des médias de communication.

Nous avons exécuté ces tests avec des sockets TCP/IP classiques et des sockets SCI. Les chiffres indiqués ci-dessous correspondent à des petits accès de 20 lignes par accès aux données. La différence entre les accès de série et par groupe diminue d'un facteur de 3-4 lorsque les lignes font 2 ko. Les sockets SCI ne sont pas testés pour les lignes de 2 ko. Les tests ont été effectués sur des clusters de 2 nœuds, avec des machines biprocesseurs, équipées de AMD 1900+.

Sélectionnez

type d'accès:         Sockets TCP/IP           Sockets SCI
Serial pk access:    400 microsecondes         160 microsecondes
Batched pk access:    28 microsecondes          22 microsecondes
Serial uk access:    500 microsecondes         250 microsecondes
Batched uk access:    70 microsecondes          36 microsecondes
Indexed eq-bound:   1250 microsecondes         750 microsecondes
Index range:          24 microsecondes          12 microsecondes

Nous avons aussi un autre jeu de tests pour comparer les performances des sockets SCI, en utilisant le transport SCI ou le transport TCP/IP. Ces tests utilisent des accès par clé primaire, en série, multithread ou multithread en groupe, simultanément.

Presque tous les tests ont montré que les sockets SCI sont 100 % plus rapides que les sockets TCP/IP. Le transporteur SCI était plus rapide dans la plupart des cas, comparés aux sockets SCI. Un cas notable : les multithreads ont montré que le transporteur SCI pouvait se comporter de très mauvaise manière, s'il est utilisé dans le processus mysqld.

Dans l'ensemble, notre conclusion est que pour les tests de performances, les sockets SCI ont amélioré la vitesse de 100 % par rapport aux sockets TCP/IP, sauf dans les rares cas où les performances ne sont pas un problème comme lors des analyses par filtres qui prennent beaucoup de temps, où lorsque de très grands groupes de clés primaires sont en jeu. Dans ce cas, le temps de calcul processeur de ndbd prend une forte part du temps de calcul.

Utiliser le transporteur SCI au lieu des sockets SCI ne sert vraiment qu'entre les processus ndbd. Utiliser le transporteur SCI ne sert que si un processeur peut être dédié à un processus ndbd, car le transporteur SCI s'assure que le processus ndbd ne reste pas inactif. Il est aussi important de s'assurer que le processus ndbd a une priorité suffisamment haute pour ne pas être rétrogradé s'il fonctionne durant un long moment (comme cela se fait en verrouillant les processus sur un processeur en Linux 2.6). Si c'est possible, alors le processus ndbd gagnera 10 à 70 % de performances, par rapport aux sockets SCI : les gains les plus importants interviennent lors des modifications, et probablement sur les analyses parallèles).

Il y a d'autres implémentations de sockets optimisées pour les clusters, indiquées dans différents articles. Elles incluent les sockets optimisées pour Myrinet, Gigabit Ethernet, Infiniband et interfaces VIA. Nous n'avons testé le cluster MySQL qu'avec les sockets SCI, et nous incluons aussi la documentation ci-dessus sur comment configurer les sockets SCI en utilisant une configuration TCP/IP ordinaire sur un cluster MySQL.

Cette section est consacrée à la liste des limitations identifiées sur la version du cluster mysql sortie en version 4.1.x, en comparaison avec les fonctionnalités connues lors de l'utilisation des moteurs de stockage MyISAM et InnoDB. À l'heure actuelle, il n'est pas prévu de remédier à ces limitations dans les futures sorties de 4.1. ; cependant nous tenterons de les traiter à travers des correctifs pour ces limitations implémentées dans MySQL 5.0 et ses prochaines versions. Si vous consultez la catégorie Cluster sur la base de données des erreurs MySQL http://bugs.mysql.com, vous trouverez la liste des erreurs connues que nous prévoyons de corriger dans les prochaines versions de MySQL 4.1 (si celles-ci sont marquées en 4.1).

Non-conformité de syntaxe (en découlent des erreurs lorsque les applications existantes sont en cours de fonctionnement) :
- les séries de caractères et les modes de collations ne sont pas tous pris en charge ; voir Section C.10.6, « MySQL Cluster-4.1.6, 10 octobre 2004 » pour une liste de celles qui le sont ;
- pas de préfixe d'index ; seuls les champs entiers peuvent être indexés ;
- les index de texte ne sont pas pris en charge ;
- les types de données « Géométrie » (WKT et WKB) ne sont pas pris en charge.
Non-conformité sur les limites / le comportement (peut mener à des erreurs lorsque les applications existantes sont en cours de fonctionnement) :
- pas de retour en arrière partiel sur les transactions. Une clé en doublon ou une erreur similaire va amener à un retour en arrière complet de la transaction ;
- un certain nombre de limites liées au disque existent, qui peuvent être configurées, mais la mémoire principale disponible dans le cluster définit la limite. Voir la liste complète des paramètres de configuration dans la Section 16.4.4, « Fichier de configuration »Fichier de configuration. La plupart des paramètres de configuration peuvent être améliorés en ligne. Ces limites disque incluent :
  - taille mémoire de la base de données et taille mémoire de l'index (respectivement DataMemory et IndexMemory),
  - nombre maximal de transactions qui peuvent être réalisées est défini en utilisant le paramètre de configuration MaxNoOfConcurrentOperations. On remarquera qu'après le chargement de masse, TRUNCATE TABLE, et ALTER TABLE sont manipulés comme des cas particuliers qui opèrent sur de multiples transactions, et qu'ils ne sont donc pas sujets à cette limitation,
  - limites relatives aux tables et index. Par exemple, le nombre maximal d'index ordonnés par table est déterminé par MaxNoOfOrderedIndexes ;
- noms de bases de données, noms de tableaux et noms d'attributs ne peuvent pas être aussi longs dans les tableaux NDB que pour d'autres gestionnaires de tableaux. Les noms d'attributs sont tronqués à 31 caractères, et s'ils ne sont pas uniques après troncature, amènent à des erreurs. Les noms de bases de données et les noms des tableaux peuvent présenter au maximum 122 caractères (c'est-à-dire, la longueur maximale pour un nom de cluster NDB est de 122 caractères, moins le nombre de caractères associé au nom de la base de données à laquelle il appartient) ;
- dans MySQL 4.1 et 5.0, toutes les lignes de tableaux du cluster sont de longueur fixe. Cela signifie (par exemple) que si une table a un ou plusieurs champs VARCHAR qui contiennent uniquement de relativement petites valeurs, plus de mémoire et d'espace disque seront nécessaires lors de l'utilisation du moteur de stockage NDB en comparaison avec le même tableau et les mêmes données stockées dans le moteur MyISAM. Nous travaillons aujourd'hui à certifier ce point dans MySQL 5.1 ;
- le nombre maximal d'objets de métadata est limité à 1600, en comptant les tableaux de bases de données, les index et les BLOB ;
- le nombre maximal d'attributs par tableau est limité à 128 ;
- la talle maximale de toute ligne est de 8 k, sans compter les données stockées dans les colonnes BLOB ;
- le nombre maximal d'attributs par clé est de 32.
Fonctionnalités non prises en charge (n'amènent pas d'erreur, mais ne sont pas prises en charge et n'ont pas d'application) :
- la clé de construction étrangère est ignorée, tout comme dans les tableaux MyISAM ;
- les points de sauvegarde et de restauration sont ignorés, tout comme dans MyISAM.
Questions de performance et liées à la limitation :
- le cache de requête est désactivé, puisqu'il n'est pas invalidé si une mise à jour a lieu sur un autre serveur MySQL ;
- questions de performance de requête liées à l'accès séquentiel du moteur de stockage NDB ; il est également plus cher de réaliser plusieurs lectures d'intervalles par cette méthode qu'avec par exemple MyISAM ou bien InnoDB ;
- la statistique de Records in range n'est pas prise en charge, ce qui résulte en des plans de requête non optimaux dans certains cas. Utiliser USE INDEX ou bien FORCE INDEXcomme solution de contournement ;
- les index uniques de restes crées avec USING HASH ne peuvent pas être utilisés pour accéder à une table si NULL est donné comme une partie de la clé.
Fonctionnalités manquantes :
- le seul niveau d'isolation pris en charge est READ_COMMITTED (InnoDB prend en charge READ_COMMITTED, REPEATABLE_READ, et SERIALIZABLE). Voir Résolution d'erreur du cluster MySQLComment restaurer une sauvegarde du cluster pour les informations sur comment ceci impacte sur les sauvegardes/restaurations de la base de données du cluster ;
- pas d'engagement solide sur le disque. Les engagements sont répliqués, mais il n'y a pas de garantie que les logs soient inscrits sur le disque à l'engagement.
Problèmes associés aux serveurs MySQL multiples (sans rapport avec MyISAM ou InnoDB) :
- ALTER TABLE ne verrouille pas complètement lorsque plusieurs serveurs MySQL sont en fonctionnement (pas de verrou réparti sur les tableaux) ;
- la réplication MySQL ne fonctionnera pas correctement si les mises à jour sont réalisées sur de multiples serveurs MySQL. Cependant, si la base de données est partitionnée selon un schéma défini au niveau des applications et s'il n'y a pas de transaction qui se passe entre ces partitions, alors la réplication peut être rendue effective ;
- la découverte automatique de bases de données n'est pas prise en charge pour les serveurs MySQL multiples qui accèdent à un même cluster MySQL. Cependant, la découverte automatique de tableaux est prise en charge dans ces cas. Cela signifie qu'après qu'une base de données nommée db_name est créée ou importée en utilisant un serveur MySQL, vous devriez adresser une déclaration CREATE DATABASE db_name; sur chaque serveur MySQL additionnel qui accède à un même cluster MySQL. (Dans le cas du MySQL 5.0.2 vous devriez également utiliser un CREATE SCHEMA db_name;.) Ceci fait pour un serveur MySQL donné, ce serveur devrait être en mesure de détecter les tableaux de bases de données sans erreur.
Sujets exclusivement en rapport avec le Cluster MySQL (non associé à MyISAM ou bien à InnoDB) :
- toutes les machines utilisées dans le cluster doivent avoir la même architecture ; c'est-à-dire, toutes les machines qui hébergent des nœuds doivent être soit en long-endian ou bien little-endian, et vous ne pouvez pas utiliser un mélange des deux types. Par exemple, on ne peut pas avoir un nœud de gestion qui opère sur un PPC et qui dirige un nœud de stockage qui fonctionne sur une machine x86. Cette restriction ne s'applique pas aux machines qui font simplement tourner mysql ou d'autres clients qui pourraient accéder aux nœuds du cluster SQL ;
- il n'est pas possible de faire des modifications de schéma en ligne telles que celles accomplies en utilisant ALTER TABLE ou bien CREATE INDEX. (Cependant on peut importer ou créer un tableau qui utilise un autre moteur de stockage, puis le convertir en NDB avec ALTER TABLE tbl_name ENGINE=NDBCLUSTER;.) ;
- ajout ou écrasement de nœuds n'est pas permis (le cluster doit être redémarré dans ces cas-là) ;
- lorsque l'on utilise de multiples serveurs de gestion, on doit donner des Id explicites aux nœuds dans des connectstrings puisque l'allocation automatique d'ID aux nœuds ne fonctionne pas simultanément sur de multiples serveurs de gestion ;
- lorsque l'on utilise de multiples serveurs de gestion, on doit être extrêmement attentif à utiliser la même configuration pour tous les serveurs de management. Le cluster n'effectuera pas de vérification particulière dans ce cas ;
- le nombre maximal de nœuds de stockage est de 48 ;
- le nombre total de nœuds dans un cluster MySQL est de 63 au maximum. Ce nombre inclut tous les serveurs MySQL (nœuds SQL), nœuds de stockage, et serveurs de gestion.

Cette liste se veut complète considérant les conditions présentées auparavant au début de la section. Vous pouvez rapporter tout écart rencontré sur la base de données des bogues MySQL http://bugs.mysql.com/. Si nous ne planifions pas de résoudre le problème dans MySQL 4.1, nous l'ajouterons à la liste ci-dessus.

Dans cette section, nous allons présenter les modifications de l'implémentation du cluster MySQL dans la version MySQL 5.0 comparée à la version MySQL 4.1. Nous allons aussi discuter de notre plan de développement pour les futures améliorations du cluster MySQL telles que prévues actuellement pour MySQL 5.1.

Dans le passé, nous avons recommandé aux utilisateurs du cluster MySQL de ne pas utiliser la version 5.0, car le cluster MySQL dans les versions 5.0 n'était pas encore totalement testé. Depuis la version 5.0.3-beta, nous avons produit une version de MySQL 5.0 avec des fonctionnalités de cluster comparables à celles de MySQL 4.1. MySQL 4.1 est toujours recommandé en production, cependant, MySQL 5.0 est de bonne qualité, et nous vous encourageons à commencer les tests avec le Cluster et MySQL 5.0 si vous pensez que vous aurez à l'utiliser en production dans le courant de l'année 2005. Il y a relativement peu de modifications entre les implémentations du cluster NDB en MySQL 4.1 et 5.0, ce qui fait que la migration devrait être rapide et sans douleur.

Depuis MySQL 5.0.3-beta, presque toutes les nouvelles fonctionnalités développées pour le cluster MySQL sont maintenant prévues dans la version 5.1. Nous vous donnerons des indications sur les futures fonctionnalités plus loin dans cette section.

16-9-1. Évolutions de MySQL Cluster en MySQL 5.0▲

MySQL 5.0.3 beta contient de nombreuses fonctionnalités :

conditions de Push-Down : une requête telle que
Sélectionnez
```
SELECT * FROM t1 WHERE non_indexed_attribute = 1;
```
va utiliser un scan de table complet, et la condition sera évaluée dans chaque nœud du cluster. Par conséquent, il n'est pas nécessaire d'envoyer les lignes à travers le réseau pour qu'elles soient évaluées : on utilise le transport de fonctions, et non pas le transport de données. Pour ce type de requête, la vitesse d'exécution s'améliore d'un facteur de 5 à 10. Notez que ce type de fonctionnalité est actuellement désactivé par défaut, en attente de plus de tests, mais il devrait fonctionner dans la plupart des cas. Cette fonctionnalité peut être activée via la commande SET engine-condition-pushdown=On;.

Autrement, vous pouvez exécuter le serveur mysqld avec cette fonctionnalité active par défaut en lançant le logiciel avec l'option de démarrage --engine-condition-pushdown.

Vous pouvez utiliser EXPLAIN pour savoir si ces conditions sont remplies.

Un avantage majeur de cette modification est que les requêtes sont maintenant exécutées en parallèle. Cela signifie que les requêtes effectuées sur des colonnes non indexées s'exécutent 5 à 10 fois, multiplié par le nombre de nœuds de stockage, plus vite que précédemment, car plusieurs processeurs sont utilisés en parallèle ;
économie de IndexMemory : en MySQL 5.0, chaque enregistrement consomme environ 25 octets en mémoire d'index, et chaque index unique utilise 25 octets par ligne en mémoire, en plus de la mémoire nécessaire au stockage dans une table séparée. Ceci est lié au fait qu'il n'y a pas de stockage de la clé primaire dans la mémoire de l'index ;
activation du cache de requête pour MySQL Cluster : voyez Section 5.11, « Cache de requêtes MySQL » pour des informations sur la configuration et l'utilisation du cache de requête ;
nouvelles optimisations : une optimisation qui mérite l'attention est que l'interface de lectures en groupe est maintenant utilisée dans certaines requêtes. Par exemple, observez la requête suivante :

Sélectionnez

SELECT * FROM t1 WHERE primary_key IN (1,2,3,4,5,6,7,8,9,10);

Cette requête sera exécutée 2 à 3 fois plus vite que dans les versions précédentes du MySQL Cluster, car les recherches d'index sont envoyées en groupe et non plus de manière unitaire.

16-9-2. Plans de développement de MySQL 5.1 pour le cluster MySQL▲

Ce qui est présenté ici est basé sur les récents ajouts dans les sources de MySQL 5.1. Il faut noter que tous les développements de la version 5.1 sont sujets à changement sans préavis.

Il y a actuellement quatre fonctionnalités majeures en cours de développement pour MySQL 5.1 :

intégration du cluster MySQL dans la réplication : cela permettra de faire des modifications de données depuis n'importe quel serveur MySQL dans le cluster, et de voir la réplication gérée par un autre serveur MySQL du cluster ;
support des enregistrements sur disques : les enregistrements sur le disque seront supportés. Les fichiers indexés, y compris les clés primaires seront toujours stockés en mémoire, mais les autres champs seront sur le disque ;
lignes à taille variable : Une colonne définie comme VARCHAR(255) occupe aujourd'hui 260 octets de stockage, indépendamment de la quantité de données réellement enregistrées. En MySQL 5.1, seule quantité utile de mémoire sera utilisée. Cela permettra de réduire considérablement les besoins en espace, par un facteur de 5 dans la plupart des cas ;
partitionnement paramétrable : les utilisateurs seront capables de définir des partitions basées sur la clé primaire. Le serveur MySQL sera capable d'ignorer certaines partitions à partir des clauses WHERE. Le partitionnement basé sur KEY, HASH, RANGE et LIST sera possible, de même que le sous-partitionnement. Cette fonctionnalité sera aussi possible avec les autres gestionnaires.

Quelle est la différence entre utiliser un cluster et utiliser une réplication ?
Dans l'installation d'un cluster, un serveur maitre mysql met à jour un ou plusieurs esclaves. Les transactions sont engagées en séquence, et une lente transaction peut amener l'esclave à trainer en suivant du maitre. Ceci signifie que si le maitre arrive en erreur, il est possible que l'esclave n'ait pas enregistré quelques-unes des dernières transactions. Si un engin de transaction sécurisée tel que InnoDB est utilisé, alors une transaction sera soit complète sur l'esclave ou bien n'aura pas lieu, mais la réplication ne garantit pas que toutes les données du maitre comme de l'esclave seront cohérentes (consistent) à chaque instant. Dans le cluster MySQL, tous les nœuds de stockage sont maintenus en synch, et une transaction engagée par n'importe lequel des nœuds de stockage engage par la suite tous les nœuds de stockage. Dans le cas d'un échec d'un nœud de stockage, les autres nœuds de stockage restants resteront dans un état cohérent.
En résumé, alors que la réplication est asynchrone, MySQL Cluster est synchrone.
Ai-je besoin d'implémenter un protocole réseau particulier pour activer les Cluster ? (Comment les ordinateurs communiquent-ils dans un cluster ?)
MySQL Cluster est destiné à être utilisé dans un environnement de large bande passante, avec des ordinateurs connectés via TCP/IP. Sa performance dépend directement de la vitesse de connexion entre le cluster d'ordinateurs. La connectivité minimum requise pour un cluster inclut un réseau passant par un Ethernet 100 mégabits ou son équivalent. Nous vous recommanderons d'utiliser un Ethernet gigabit tant que faire se peut.
Le plus rapide protocole SCI est également pris en charge, mais demande un (hardware) particulier. Voir MySQL Cluster Interconnects pour plus d'informations sur les SCI.
De combien d'ordinateurs ai-je besoin pour démarrer un cluster, et pourquoi ?
Un minimum de trois ordinateurs est attendu pour faire tourner un cluster viable. Cependant, le minimum recommandé d'ordinateurs dans un cluster mysql est de quatre : deux d'entre eux pour respectivement héberger la gestion et les nœuds SQL, et deux ordinateurs pour servir de nœuds de stockage. L'intérêt d'avoir deux nœuds de stockage est de procurer la redondance ; le nœud de gestion doit tourner sur une machine séparée afin de garantir un arbitrage continu des services dans le cas où l'un des nœuds de stockage se met en échec.
Que font les différents ordinateurs dans un cluster ?
Un cluster MySQL présente à la fois une organisation physique et une organisation logique, dans laquelle les ordinateurs sont les éléments physiques. Les éléments logiques ou fonctionnels d'un cluster sont référencés en tant que nœuds, et un ordinateur qui héberge un nœud de cluster est parfois référencé en tant qu'hôte de cluster. Idéalement, il devrait y avoir un nœud par hôte de cluster, bien qu'il soit possible de faire tourner de multiples nœuds sur un unique hôte. Il y a trois types de nœuds, chacun correspondant à un rôle spécifique au sein du cluster. Ce sont :
1. Nœud de Gestion (nœud MGM): Ce nœud procure les services de gestion pour l'ensemble du cluster, y compris le démarrage, la fermeture, les backups et la configuration de données pour les autres nœuds. Le nœud de gestion serveur est implémenté dans l'application ndb_mgmd, le nœud de gestion client utilisé pour contrôler le cluster MySQL à travers le nœud de MGM est le ndb_mgm ;
2. Nœud d'empilement (nœud de données) : empile et réplique les données. La fonctionnalité de nœud d'empilement est gérée par une instance process du nœud de stockage NDB ndbd ;
3. Nœud SQL : Il s'agit simplement d'une instance de MySQL Server (mysqld) qui a démarré avec l'option --ndb-cluster.
Avec quel système d'exploitation puis-je utiliser le Cluster ?
En version 4.1.10, le cluster MySQL est officiellement pris en charge sous Linux, Mac OS X, et Solaris. Nous travaillons actuellement à l'ajout de support pour le Cluster sous d'autres plateformes, y compris sous Windows (le support Windows devrait être opérationnel pour MySQL 5.0), et notre objectif est finalement de rendre le cluster opérationnel sur toutes les plateformes pour lesquelles MySQL est lui-même pris en charge.
Il devrait être possible d'utiliser les process cluster sur d'autres systèmes d'exploitation (y compris Windows), mais pour ceux-ci, mis à part pour les trois précédemment cités, les process cluster doivent être considérés comme des logiciels « alpha » et pas comme outils de production en tant que tels.
Quelle est la configuration matérielle nécessaire pour utiliser le Cluster MySQL ?
Le Cluster devrait être utilisable sur toute plateforme qui est en mesure de faire tourner les binaires actifs-NDB. Il est évident que les CPU les plus rapides et une grande capacité mémoire amélioreront la performance, et les CPU de 64 bits seront probablement plus efficaces que les processeurs 32 bits. Les machines utilisées pour les nœuds de stockage doivent posséder une quantité suffisante de mémoire afin de pouvoir effectuer tous les partages pour tous les nœuds de la base de données puissent tous avoir lieu (voir la question « Combien de RAM pour le Cluster ? » pour plus informations). Les nœuds peuvent communiquer via un réseau et un matériel TCP/IP standard. Pour la prise en charge de SCI, un matériel réseau dédié sera requis.
Puisque le Cluster MySQL utilise le TCP/IP, est-ce que je peux le faire tourner en passant par Intenet, avec un ou plusieurs nœuds positionnés à l'extérieur ?
Il faut garder à l'esprit que la communication entre les nœuds d'un Cluster MySQL ne sont pas sécurisés ; ils ne sont ni encryptés ni protégés par une autre sorte de mécanisme. La configuration la plus sécurisée pour un Cluster est définie par un réseau privé protégé sous un pare-feu, sans accès direct de l'extérieur à aucune donnée du Cluster ni à l'un des nœuds de gestion.
Il y a peu de chances dans tous les cas qu'un cluster fonctionne de façon fiable dans de telles conditions, étant donné que le cluster MySQL a été conçu et implémenté suivant l'hypothèse qu'il tournerait dans des conditions qui garantissent une connectivité à haut débit réservée à ses échanges, similaires à celles que l'on trouve dans les installations LAN à base de 100 Mbps ou bien en Ethernet gigabit. La performance de cluster n'a jamais été testée ni garantie en cas de connectivité inférieure à ces débits.
Dois-je apprendre un nouveau langage de programmation ou de commande pour utiliser le Cluster ?
Non. Tandis que certaines commandes spécialisées sont utilisées pour gérer et configurer le cluster en lui-même, seules des requêtes et commandes MySQM standard sont requises pour :
- créer, modifier et tomber les tableaux ;
- insérer, mettre à jour et effacer les données des tableaux ;
- créer, changer et laisser tomber des index uniques et primaires ;
- configurer et gérer les nœuds MySQL (serveurs MySQL).
Comment faire pour trouver la signification d'un message d'avertissement ou d'erreur lorsque j'utilise le Cluster ?
Il y a deux manières de procéder pour cela :
1. Au sein même du Moniteur MySQL, utiliser la fonctionnalité AFFICHER ERREUR ou respectivement AFFICHER AVERTISSEMENT immédiatement après la notification d'erreur ou d'avertissement. Les messages peuvent également être affichés dans le navigateur de requêtes MySQL ;
2. À partir d'une fenêtre de commande, utiliser le code d'erreur perror --ndb error-code.
Est-ce que le Cluster MySQL effectue des transactions sécurisées ? Quels types de tableaux le Cluster prend-il en charge ?
Oui. Le Cluster MySQL est mis en place pour des tableaux créés avec le moteur de stockage NDB, qui prend en charge les transactions. NDB est le seul moteur de stockage NDB qui prend en charge les structures de cluster.
Que signifie le terme « NDB » ?
Cela signifie « Base de données Réseau », en anglais « Network Database ».
Quelle(s) version(s) du logiciel MySQL prend en charge le Cluster ? Dois-je le compiler à la source ?
Le Cluster est pris en charge dans les binaires MySQL-max à partir de la version 4.1.3. À vous de déterminer si votre serveur binaire prend en charge le NDB grâce aux commandes SHOW VARIABLES LIKE 'have_%'; ou bien SHOW ENGINES;. (Voir Section 5.1.2, « mysqld-max, la version étendue du serveur mysqld » pour un complément d'information.)
Pour les utilisateurs sous Linux, veuillez considérer que le NDB n'est pas inclus dans les RPM ; il est recommandé en revanche d'utiliser les binaires fournis en tant qu'archives .tar.gz dans la zone de téléchargement MySQL Downloads area . Vous pouvez également obtenir la prise en charge de NDB en compilant les binaires -max à partir de la source, mais ce n'est pas nécessaire pour simplement utiliser le Cluster MySQL.
Quelle est la quantité de RAM nécessaire ? Est-il éventuellement envisageable d'avoir recours à la mémoire disque ?
À l'heure actuelle, le Cluster est uniquement en mémoire. Cela signifie que toutes les données des tableaux (index inclus) sont stockés dans la RAM. Par conséquent ; si vos données occupent jusqu'à 1 gigabyte d'espace et que vous voulez les répliquer une fois dans le cluster, vous aurez besoin de 2 gigabytes de mémoire pour que ce soit faisable. Ceci s'ajoute à la mémoire requise par le système exploitation et celle occupée par toutes les applications qui fonctionnent sur les ordinateurs du cluster.
Vous pouvez utiliser la formule suivante pour obtenir une estimation approchée de la quantité de RAM requise pour chaque nœud de stockage dans le cluster :

Sélectionnez

(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfStorageNodes

Pour calculer plus précisément la mémoire nécessaire, on aura besoin de déterminer, pour chaque tableau de la base de données du cluster, l'espace de stockage requis par ligne (voir Section 11.5, « Capacités des colonnes » pour une méthode détaillée), puis multiplier cette valeur par le nombre de lignes. Vous devez également vous rappeler de prendre en compte tous les index de colonnes selon :

dans MySQL 4.1., chaque clé primaire ou index de règle créé pour un tableau de cluster NDB requiert 25 bytes de stockage par enregistrement, en plus de l'espace associé à la clé. Dans My SQL 5.0, cette quantité est réduite de 21 à 25 bytes par enregistrement. Ces index utilisent IndexMemory ;
chaque index ordonné requiert 10 bytes de stockage par enregistrement, en utilisant DataMemory ;
créer une clé primaire ou un index unique crée également un index ordonné, à moins que cet index soit créé avec USING HASH. En d'autres termes, s'il est créé sans USING HASH, une clé primaire ou un unique index sur un tableau de cluster occupera 35 bytes (en plus de la taille de la clé)par enregistrement pour MySQL 4.1, et 31-35 bytes par enregistrement pour MySQL 5.0.
On remarquera que créer des tableaux de Cluster MySQL avec USING HASH pour toutes les clés primaires et les index uniques va généralement amener à des mises à jour de tableaux pour fonctionner plus rapidement. Ceci résulte du fait que moins de mémoire est requise (puisqu'aucun index ordonné n'est créé) et que l'on a besoin de moins utiliser le CPU (puisque moins d'index sont à lire et probablement à mettre à jour).
Il est tout particulièrement important de garder à l'esprit que tous les tableaux de Cluster MySQL doivent avoir une clé primaire, et que le moteur de stockage NDB va créer une clé primaire automatiquement si aucune n'est explicitement spécifiée, sachant que cette clé est créée sans le USING HASH.
On voit souvent des questions d'utilisateurs qui rapportent que, lorsqu'ils essaient de remplir une base de données cluster, le processus de chargement se termine prématurément et qu'un message d'erreur semblable à celui ci-dessous s'affiche alors :
Sélectionnez
```
ERROR 1114: The table 'my_cluster_table' is full
```
Lorsque cela se produit, la source provient très probablement du fait que votre installation ne possède pas de suffisamment de mémoire RAM pour toutes les données des tableaux et tous les index, y compris la clé primaire requise par le NDB.

It is also worth noting that all storage nodes should have the same amount of RAM, as no storage node in a cluster can use more memory than the least amount available to any individual storage node. In other words, if there are three computers hosting Cluster storage nodes, with two of these having three gigabytes of RAM available to store Cluster data, and one having only one GB RAM, then each storage node can devote only one GB for Cluster.
Dans un cas de défaillance catastrophique - disons par exemple, une coupure de courant dans la ville entière ET mon alimentation de secours ne fonctionne pas - est-ce que je perdrais mes données ?
Toutes les transactions engagées sont tracées. Par conséquent, bien qu'il soit envisageable qu'une partie des données soit perdue dans un cas de catastrophe, ce phénomène devrait tout de même être relativement réduit. Les risques de pertes de données peuvent être encore réduits par la minimisation du nombre d'opérations par transaction.
Est-il possible d'utiliser des index FULLTEXT avec le Cluster?
L'indexation par FULLTEXT n'est pas actuellement (en MySQL 4.1.9) prise en charge par le moteur de stockage NDB. L'ajout de cette fonctionnalité est prévu pour les prochaines versions.
Puis-je faire tourner plusieurs nœuds sur un même ordinateur ?
C'est en effet réalisable, mais pas recommandé. L'une des raisons majeures de travailler avec un cluster est de disposer d'une redondance ; et afin de profiter au mieux des apports de cette redondance, chaque nœud devrait être placé sur une machine séparée. Si l'on place plusieurs nœuds sur une même machine et que cette machine est défaillante, on perd tous les nœuds qu'elle contenait. Étant donné que le Cluser MYSQL peut fonctionner sur du matériel partagé, et chargé sur un système d'exploitation peu cher ou même gratuit, il est préférable pour des raisons d'économies d'acheter une ou deux machines de plus pour sauvegarder les données critiques de la mission. Il est également important de remarquer que la configuration système pour un hôte de cluster qui héberge un nœud de gestion est presque minimaliste ; cette tâche peut être réalisée avec un simple processeur Pentium à 200 MHz et suffisamment de RAM pour le système d'exploitation, en plus d'un simple surplus pour les process ndb_mgmd et ndb_mgm.
Puis-je ajouter des nœuds à un cluster sans le redémarrer ?
Pas à l'heure actuelle. Un simple redémarrage suffit pour ajouter de nouveaux nœuds de gestion à un Cluster. Lorsqu'on ajoute des nœuds de stockage, le processus est plus complexe et nécessite les étapes suivantes :
- effectuer une sauvegarde complète de toutes les données du cluster ;
- fermeture totale du cluster et de tous les process de nœuds de cluster en cours ;
- redémarrer le cluster, en utilisant l'option de démarrage -initial ;
- restaurer toutes les données de cluster à partir de la sauvegarde.
Dans le futur, l'implémentation d'une capacité de reconfiguration « à chaud » du Cluster MySQL est prévue afin de minimiser, à défaut d'éliminer ces requis pour le redémarrage du Cluster lors de l'ajout de nouveaux nœuds.
Quelles sont les limitations dont je devrais être informé dans le cadre de l'utilisation du Cluster ?
Les tableaux NDB de MySQL 4.1 sont soumis aux limitations suivantes :
- certains ensembles de caractères et de collations ne sont pas pris en charge. (Pour une liste complète de ceux qui sont pris en charge, voir Section C.10.6, « MySQL Cluster-4.1.6, 10 octobre 2004 ») ;
- les index et préfixes FULLTEXT ne sont pas pris en charge. Seules les colonnes complètes peuvent être indexées ;
- les données spatiales MySQL ne sont pas prises en charge (voir Chapitre 18, Données spatiales avec MySQLChapitre 18. Données spatiales avec MySQL) ;
- seules les restaurations complètes sont prises en charge pour les transactions. Les restaurations partielles et restaurations à partir de points de sauvegarde ne sont pas prises en charge ;
- se nombre maximal d'attributs autorisés par tableau est de 128, et les noms d'attributs ne peuvent pas excéder la longueur de 31 caractères. Pour chaque tableau, la longueur maximale combinée des noms du tableau et de la base de données est de 122 caractères ;
- la taille maximale d'une ligne de tableau est de 8 kilobytes, sans compter les BLOB. Il n'y a pas de limite définie pour le nombre de lignes par tableau ; la taille limite du tableau dépend d'un certain nombre de paramètres, et en particulier la taille de la RAM disponible pour chaque nœud de données ;
- le moteur NDB ne prend pas en charge les contraintes de clés étrangères. De même qu'avec les tableaux MyISAM, ces clés sont ignorées ;
- le cache de requête n'est pas pris en charge.
Il est prévu de remédier à ces restrictions dans le MySQL 5.0. Pour un complément d'information sur les limitations actuelles, voir Section 16.8, « Cluster Limitations in MySQL 4.1 »Limitations du cluster dans MySQL 4.1.
Comment puis-je importer une base de données MySQL existante dans un cluster ?
On peut importer des bases de données dans le Cluster MySQL à peu près de la même manière que l'on ferait pour une autre version de MySQL. En dehors des limitations mentionnées précédemment, la seule particularité est que tout tableau qui est destiné à être inclus dans le cluster doit utiliser le moteur de stockage NDB. Ceci signifie que les tableaux doivent être créés avec l'option ENGINE=NDB ou bien ENGINE=NDBCLUSTER.
Comment les nœuds de cluster communiquent-ils entre eux ?
Les nœuds de cluster peuvent communiquer selon trois protocoles distincts: TCP/IP, SHM (mémoire partagée, « shared memory » en anglais), et SCI (Interface ajustable cohérente, ou bien « Scalable Coherent Interface » en anglais). Lorsqu'il est utilisable, le protocole SHM est utilisé par défaut entre les nœuds qui partagent le même hôte de cluster. Le SCI est un protocole à haut débit (1 gigabit par seconde et plus), et à grande capacité, largement utilisé dans la construction de systèmes à multiprocesseurs ajustables ; il requiert l'installation de matériel et de drivers adaptés. Voir la Section 16.7, « Utilisation d'interconnexions haute vitesse avec MySQL Cluster »Utilisation d'interconnexions haute vitesse avec MySQL Cluster pour en savoir plus sur l'utilisation du SCI comme support de transfert dans le Cluster MySQL.
Qu'est-ce qu'un arbitre ?
Si un ou plusieurs nœuds d'un cluster se trouvent défaillants, il est possible que les nœuds du cluster n'étaient pas en mesure de se « voir » tous les uns les autres. En fait, il est possible que deux ensembles de nœuds s'isolent l'un de l'autre au sein de la partition réseau, un phénomène aussi connu sous le terme de scénario du « cerveau divisé ». Ce type de situation est indésirable parce que chaque ensemble de nœuds tente de se comporter comme s'il constituait le cluster en entier.
Lorsque les nœuds de cluster se séparent, on a deux options. Si plus de 50 % des nœuds restants continuent à communiquer entre eux, alors il s'agit d'une situation appelée parfois « règle du plus grand nombre », et cet ensemble de nœuds est considéré comme le nouveau cluster. L'arbitre entre en jeu lorsqu'il y a un nombre égal de nœuds de chaque côté : dans ce cas, l'ensemble de nœuds auquel l'arbitre est lié est considéré comme le cluster ; et les nœuds qui n'appartiennent pas à cet ensemble sont éteints par le système.
La situation précédente est parfois simplifiée ; une explication plus complète qui prend en compte les groupes de nœuds suit ci-dessous :
Lorsque tous les nœuds dans au moins un nœud de groupe sont actifs, la partition réseau n'est pas un problème, parce qu'une unique portion du cluster ne peut constituer un cluster fonctionnel. Le problème se pose lorsque dans les nœuds de groupe individuel, tous les nœuds ne sont pas actifs, et dans ce cas la partition réseau devient possible (scénario du « cerveau divisé »). Alors un arbitre est nécessaire. Tous les nœuds du cluster reconnaissent le même nœud comme arbitre, ce qui est normalement le serveur de gestion ; cependant il est possible de configurer n'importe lequel des serveurs MySQL du cluster pour agir en tant qu'arbitre au lieu de serveur. L'arbitre accepte le premier des ensembles de nœuds de cluster qui le contacte, et ordonne au restant des nœuds de s'éteindre. La sélection de l'arbitre est contrôlée par le paramètre de configuration ArbitrationRank pour le serveur MySQL et pour les nœuds de gestion du serveur. (Voir Section 16.4.4.4, « Définition du serveur de gestion du cluster »Définition du serveur de gestion du cluster pour les détails complémentaires.) Il faut également remarquer que le rôle de l'arbitre n'est pas de liquider les nœuds ni d'imposer lui-même une demande forte sur l'hôte qui l'a désigné, et donc l'arbitre ne nécessite pas particulièrement un haut débit de communication ou de mémoire additionnelle spécialement dédiée à cette tâche.
Quels sont les types de colonnes prises en charge par le Cluster MySQL ?
Le Cluster MySQL prend en charge tous les types de colles habituels de MySQL, à l'exception de celles mentionnées dans le Chapitre 18, Données spatiales avec MySQLChapitre 18. Données spatiales avec MySQL. De plus, il y a quelques différences pour ce qui concerne les index en comparaison avec les tableaux NDB. Remarque : Dans MySQL 4.1 et 5.0, les tableaux de Cluster (c'est-à-dire, les tableaux créés avec ENGINE=NDBCLUSTER) ont uniquement des lignes de largeur fixe. Ceci signifie que (par exemple), chaque enregistrement qui contient une colonne VARCHAR(255) va demander 256 bytes de stockage pour cette colonne, indépendamment de la taille des données contenues dans la colonne. Il est prévu de traiter ce point dans le MySQL 5.1.
Voir Section 16.8, « Cluster Limitations in MySQL 4.1 »Limitations du cluster dans MySQL 4.1 pour plus d'informations sur ces questions.
Comment démarrer et arrêter le Cluster MySQL ?
Il est nécessaire de démarrer chaque nœud du cluster séparément, dans un ordre donné :
1. Démarrer le nœud de gestion avec la commande ndb_mgmd ;
2. Démarrer chaque nœud de stockage avec la commande ndbd ;
3. Démarrer chaque serveur MySQL (nœud SQL) avec mysqld_safe --user=mysql &.
Chacune de ces commandes doit être lancée à partir de la cellule sur la machine hôte du nœud concerné. On peut vérifier que le cluster est fonctionnel en démarrant la gestion client MGM ndb_mgm sur la machine du nœud de gestion MGM.
Qu'arrive-t-il aux données du cluster lorsque le cluster est éteint ?
Les données contenues en mémoire par les nœuds de stockage du cluster sont écrites sur le disque, et seront rappelées en mémoire lorsque le cluster démarre la fois suivante.
Pour éteindre le cluster, entrer le code suivant dans une fenêtre de commande sur la machinque hôte pour le nœud de gestion :
Sélectionnez
```
shell> ndb_mgm -e shutdown
```
Cette action va amener le ndb_mgm, ndb_mgm, et tous les process ndbd à se fermer progressivement. Les serveurs MySQL qui fonctionnent en tant que nœuds de Cluster SQL peuvent être éteints avec la commande mysqladmin shutdown.

Pour plus d'informations, voir la Section 16.6.1, « Commandes du client de gestion du Cluster »Commandes du client de gestion du Cluster et la Section 16.3.6, « Arrêt et redémarrage du cluster »Arrêt et redémarrage du cluster.
Est-ce utile d'avoir plus d'un nœud de gestion pour un cluster ?
Cela peut être un recours en tant que soutien en cas d'erreur. Un unique nœud de gestion MGM contrôle à lui seul le cluster à un moment donné du temps, mais il est possible de configurer un nœud de gestion comme source principale de commande, et un second ou plusieurs autres nœuds destinés à prendre le relais dans le cas où le nœud principal vient à l'erreur.
Puis-je recourir à plusieurs types de matériel et de systèmes d'exploitation dans un Cluster ?
Oui, tant que toutes les machines et tous les systèmes d'exploitation sont du même type endian. Il est également possible d'utiliser plusieurs types de versions de cluster MySQL Cluster sur des nœuds distincts (par exemple, 4.1.8 sur certains nœuds et 4.1.9 sur d'autres). Cependant, cette configuration n'est recommandée que dans le cadre d'une mise à jour glissante.
Puis-je utiliser deux nœuds de stockage sur un même hôte ? Et deux nœuds SQL ?
Oui, cette configuration est réalisable. Dans le cas de nombreux nœuds de stockage, chaque nœud doit utiliser un répertoire de données distinct. Si l'on veut utiliser plusieurs nœuds SQL sur une même machine, alors chaque cas de mysqld doit utiliser un port TCP/IP distinct.
Puis-je nommer les hôtes dans le Cluster MySQL ?
Oui, il est envisageable d'utiliser des DNS et DHCP en tant qu'hôtes de cluster. Cependant, si votre application requiert une disponibilité « 24 heures sur 24 », il est recommandé d'utiliser des adresses IP fixes. Ceci vient du type de communication entre les hôtes de cluster pour lesquels il existe une dépendance à ces services ; cette architecture a tendance à créer des points de rupture additionnels dont on préfère se passer.

Les termes suivants sont utiles lorsqu'on veut comprendre le MySQL Cluster ou bien connaître le sens particulier des expressions qu'il utilise.

Cluster : dans son sens générique, un cluster est un ensemble d'ordinateurs qui fonctionnent comme une même unité et qui travaillent ensemble pour réaliser une tâche unique. NDB Cluster est la machine d'empilement utilisée par MySQL pour implémenter le stockage des données, le renvoi des données, et la gestion distribuée entre plusieurs ordinateurs. MySQL Cluster fait référence à un groupe d'ordinateurs qui travaillent ensemble en utilisant la machine NDB en tant que support à une base de données distribuée MySQL dans une architecture de non-partage utilisant un empilement dans un empilement en mémoire.
Fichiers de configuration : fichiers texte qui contiennent les directives et l'information en rapport avec le cluster, ses hôtes, et ses nœuds. Ceux-ci sont lus par les nœuds de gestion du cluster lorsque le cluster démarre. Voir Section 16.4.4, « Fichier de configuration »Fichier de configuration pour les détails.
Sauvegarde : une copie complète de toutes les données du cluster, les transactions et les logs, sauvegardés sur le disque ou tout autre type de stockage à long terme.
Restauration : retour du cluster dans un état précédent, stocké préalablement en sauvegarde.
Point de contrôle : de manière générale, lorsque les données sont sauvegardées sur le disque, on dit qu'un point de contrôle a été atteint. Plus spécifiquement dans le cas du cluster, il s'agit d'un point dans le temps auquel tous les engagements de transactions sont stockés sur le disque. Dans le cas du moteur de stockage DB, deux sortes de points de contrôle travaillent simultanément pour assurer que la cohésion d'ensemble du cluster est maintenue :
- point de contrôle local (LCP): ce point de contrôle est spécifique à un nœud donné ; cependant les LCP sont mis en place pour tous les nœuds du cluster plus ou moins simultanément. Un LCP implique la sauvegarde de toutes les données d'un nœud sur le disque , et sera donc faite à des intervalles séparés de quelques minutes. La durée exacte de l'intervalle varie, et dépend de la quantité de données contenue dans le nœud, du niveau d'activité du cluster, et d'autres facteurs ;
- point de contrôle global (GCP): un point de contrôle global prend place à des intervalles de quelques secondes, lorsque les transactions pour tous les nœuds sont synchronisées et lorsque le redo-log est inscrit en mémoire.
Hôte cluster : un ordinateur qui fait partie du cluster MySQL. Un cluster possède à la fois une structure physique et une structure logique. Physiquement, le cluster comporte un certain nombre d'ordinateurs, appelés hôtes de cluster (ou plus simplement hôtes). Voir aussi nœuds, groupes de nœuds.
Nœud : ce terme fait référence à une unité logique ou fonctionnelle du cluster MySQL, parfois aussi appelé nœud de cluster. Dans le cadre d'un cluster MySQL, on utilise le terme nœud pour désigner un processus plutôt qu'un élément physique du cluster. Trois types de nœuds sont nécessaires pour mettre en place un MySQL Cluster fonctionnel :
- nœuds de Gestion (MGM) : gère les autres nœuds du cluster MySQL. Fournit les données de configuration aux autres nœuds ; démarre et ferme les nœuds ; organise le partitionnement du réseau ; crée des sauvegardes et des restaurations de données ; etc. ;
- nœuds MySQL (serveur MySQL) : cas de serveur MySQL utilisés en tant que face avant aux données conservées dans les nœuds de stockage du cluster. Les clients qui désirent stocker, récupérer, ou mettre à jour des données peuvent accéder aux nœuds d'un SQL de même qu'à tout autre Serveur MySQL, en employant les méthodes usuelles d'authentification et d'API ; la distribution sous-jacente des données entre les groupes de nœuds est transparente pour les utilisateurs et pour les applications. Les nœuds SQL accèdent aux bases de données du cluster dans leur ensemble sans faire de distinction sur la distribution de données entre les différents points de stockage ou entre les hôtes du cluster ;
- nœuds de données (ou encore nœuds de stockage) : ces nœuds stockent les données de travail. Les fragments de tableaux de données sont stockés dans un ensemble de groupes de nœuds ; chaque groupe de nœuds contient une des sous-parties du tableau de données. Chacun des nœuds qui forment un groupe de nœuds emmagasine une réplique du fragment dont il est en charge. À l'heure actuelle, un seul cluster peut prendre en charge un total de plus de 48 nœuds.
Il peut arriver que plusieurs nœuds coexistent sur une même machine. (En fait, il est même possible d'installer un cluster complet sur une seule machine, bien que ce ne soit pas désirable dans un environnement de production.) Il peut être utile de se rappeler que, lorsqu'on travaille avec un cluster MySQL, le terme d'hôte fait référence à un composant physique du cluster tandis que le terme nœud désigne un composant logique ou fonctionnel (c'est-à-dire, un processus).
Remarque concernant les termes obsolètes : dans les anciennes versions de la documentation du cluster MySQL, les nœuds de données étaient parfois désignés comme des « nœuds de la base de données », ou bien « nœuds de DB ». De plus, les nœuds SQL étaient parfois définis comme des « nœuds clients » ou bien « nœuds d'API ». Cette ancienne terminologie a été abandonnée pour des raisons de clarté, et il est donc conseillé d'éviter de l'utiliser.
Nœud de groupe : ensemble de nœuds de données. Tous les nœuds de données d'un même nœud de groupe contiennent les mêmes données (fragments), et tous les nœuds dans un même groupe devraient se situer sur des hôtes distincts. Il est possible de contrôler l'appartenance des nœuds de données à un nœud de groupe particulier.
Échec de nœud : le cluster mysql n'est pas uniquement dépendant du fonctionnement d'un unique nœud le composant ; le cluster peut continuer à tourner si l'un ou plusieurs de ses nœuds entrent en échec. Le nombre précis d'échecs de nœuds tolérables pour le cluster dépend du nombre de nœuds qu'il contient ainsi que de la configuration du cluster.
Redémarrage de nœud : procédure de redémarrage d'un nœud de cluster.
Redémarrage de nœud initial : procédure de démarrage d'un nœud de cluster en retirant son filesystem. Parfois utilisé au cours d'une mise à jour logicielle et dans d'autres circonstances particulières.
Crash Système (ou bien Échec Système) : arrive lorsqu'une trop grande quantité de nœuds de cluster sont en échec et que l'état du cluster ne peut plus être considéré comme fonctionnel.
Redémarrage système : procédure de redémarrage du cluster et de réinitialisation de son état sur la base de log disque ou de points de contrôle. Nécessaire après une fermeture planifiée ou pas du cluster.
Fragment : partie d'un tableau de base de données ; dans le moteur de stockage NDB, un tableau est ainsi découpé et stocké en un certain nombre de fragments. Un fragment est aussi parfois appelé une partition. Cependant on préférera le terme de « fragment ». Les tableaux sont fragmentés dans un cluster mysql de façon à faciliter la répartition du poids des données entre les machines et les nœuds.
Réplique : sous le moteur de stockage NDB, chaque fragment de tableau possède un certain nombre de répliques réparties sur des nœuds de stockage distincts afin de produire la redondance. Aujourd'hui, chaque fragment est de capacité de contenir au maximum 4 répliques.
Transporteur : protocole qui assure le transfert de données entre les nœuds. À l'heure actuelle, le cluster mysql gère quatre types distincts de connexions par transporteur : TCP/IP (en local), TCP/IP (à distance), SCI et SHM (encore en test dans Mysql 4.1.) :
- TTCP/IP est bien sûr le protocole réseau bien connu qui transmet les HTTP, FTP, etc., sur l'Internet ;
- SCI (« Scalable Coherent Interface », ou Interface Cohérente Evolutive) est un protocole de haut débit utilisé pour construire des systèmes de multiprocesseurs et les applications de process parallèles. L'utilisation d'un SCI avec le cluster mysql demande un matériel spécialisé et est détaillé dans la Section 16.7.1, « Configurer le cluster MySQL avec les sockets SCI »Configurer le cluster MySQL avec les sockets SCI. Pour des notions de base en utilisation du SCI, voir l'essai sur dolphinics.cominics.cominics.com ;
- SHM traduit la fragmentation des segments de la mémoire en écriture Unix (« shared memory segments »). Lorsqu'on peut l'appliquer, SHM est utilisé automatiquement pour connecter les nœuds hébergés sur un même hôte. Cette fonctionnalité est encore en test sur MySQL 4.1, mais une implémentation complète est planifiée en MySQL 5.0. La page Unix pour shmop(2) est un bon début pour des informations complémentaires à ce sujet.
Nœud : le transporteur de cluster est à l'intérieur du cluster. Les applications qui utilisent le cluster mysql communiquent avec les nœuds sql de la même façon qu'elles le feraient avec d'autres versions du serveur mysql (via un TCP/IP ou un canal de noms windows/prises unix). Les requêtes peuvent être envoyées et les résultats récupérés en utilisant les API standards.
NDB (Base de données réseau ou « Network Database ») : référence au moteur de stockage utilisé pour activer le cluster mysql. Le stockage NDB travaille avec tous les types usuels de colonnes mysql, les déclarations mysql et se conforme à l'ACID. Ce moteur fournit également le support pour les transactions (engagements et retour en arrière).
Architecture de non-partage : architecture idéale pour un cluster mysql. Dans une installation réellement sans partage, chaque nœud fonctionne sur un hôte distinct. L'avantage d'une telle organisation est qu'un unique hôte ou nœud qui se trouve en échec n'amène pas à un point de défaillance unique ni à une perte de performance pour l'ensemble du système.
Stockage en mémoire interne : toutes les données stockées dans un nœud donné sont gardées en mémoire sur l'ordinateur qui héberge le nœud. Pour chaque nœud de données dans le cluster, vous devez posséder une quantité de RAM disponible égale à celle de la base de données multipliée par le nombre de répliques et divisée par le nombre de nœuds de données. Par exemple, si une base de données occupe un espace mémoire de 1 gigabyte, et que vous voulez installer le cluster avec 4 répliques et 8 nœuds de données, un minimum de 500 MB de mémoire par nœud sera nécessaire. On remarquera que cette contrainte s'ajoute à toutes celles précédemment définies pour la configuration système, en plus des applications en cours de fonctionnement sur l'hôte des nœuds.
Tableau : ainsi qu'attendu dans les contextes d'une base de données relationnelle, le terme de « tableau » fait référence à un ensemble ordonné d'enregistrements structurés à l'identique. Dans le Cluster MySQL, un tableau de base de données est stocké dans un nœud de données en tant qu'ensemble de fragments, dont chacun est répliqué sur des nœuds de données additionnels. L'ensemble des nœuds de données qui répliquent le même fragment ou bien ensemble de fragments est nommé nœud de groupe.
Programmes de Clusters : il s'agit de programmes de lignes de commande utilisés dans le fonctionnement, la configuration et l'administration du Cluster MySQL. Ils incluent les deux daemons serveurs :
- ndbd: le nœud de données daemon (fait tourner les process de nœuds de données) ;
- ndb_mgmd: serveur de gestion daemon (fait tourner les process de gestion de serveur).
Et les programmes clients :
- ndb_mgm: la gestion de client (amène une interface pour exécuter les commandes de gestion) ;
- ndb_waiter: utilisé pour vérifier les statuts de tous les nœuds d'un cluster ;
- ndb_restore: restore les données de cluster à partir d'un backup.
Pour en savoir plus sur ces programmes et leurs utilisations, voir la Section 16.5, « Serveur de gestion du cluster MySQL »Serveur de gestion du cluster MySQL.
Rapport d'événement : le Cluster MySQL reporte les événements par catégorie (démarrage, fermeture, erreurs, points de vérification, etc. ), par priorité et par criticité. Une liste complète de l'ensemble des événements reportés est disponible dans la Section 16.6.2, « Rapport d'événements générés par le cluster MySQL »Rapport d'événements générés par le cluster MySQL. Les rapports d'événements sont de deux types :
- rapport de Cluster : garde un enregistrement d'ensemble de tous les événements intéressants à reporter pour le Cluster ;
- rapport de nœud : un rapport individuel est également enregistré pour chaque nœud.
Dans des circonstances normales, il est nécessaire et suffisant de garder et d'examiner uniquement le rapport de cluster. Le rapport de nœuds est à consulter uniquement pour les développements d'applications et pour le débogage.

Manuel de référence MySQL 5.0

16. Introduction à MySQL Cluster▲

16-1. Présentation de MySQL Cluster▲

16-2. Concepts de base de MySQL Cluster▲

16-3. Configuration simple multiserveur▲

16-3-1. Matériel, logiciels et réseau▲

16-3-2. Installation▲

16-3-3. Configuration▲

16-3-4. Démarrage initial▲

16-3-5. Charger les données d'exemple et exécuter des requêtes▲

16-3-6. Arrêt et redémarrage du cluster▲

16-4. Configuration de MySQL Cluster▲

16-4-1. Compilation du cluster▲

16-4-2. Installation du logiciel▲

16-4-3. Vérification rapide du fonctionnement du cluster▲

16-4-4. Fichier de configuration▲

16-4-4-1. Exemple de configuration d'un cluster MySQL▲

16-4-4-2. La chaîne connectstring du Cluster MySQL▲

16-4-4-3. Définition des ordinateurs dans un cluster MySQL▲

16-4-4-4. Définition du serveur de gestion du cluster▲

16-4-4-5. Définitions des nœuds de stockage dans un cluster MySQL▲

16-4-4-6. Définition des serveurs MySQL dans un Cluster MySQL▲

16-4-4-7. Définition des connexions TCP/IP dans un cluster MySQL▲

16-4-4-8. Définition des connexions par mémoire partagée dans un cluster MySQL▲

16-4-4-9. Définition d'un transporteur SCI dans un cluster▲

16-5. Serveur de gestion du cluster MySQL▲

16-5-1. Utilisation des processus serveurs MySQL par MySQL Cluster▲

16-5-2. ndbd, le processus de stockage du cluster▲

16-5-3. ndb_mgmd, le serveur de gestion▲

16-5-4. ndb_mgm, le client de gestion du cluster▲

16-5-5. Options des commandes pour le cluster MySQL▲

16-5-5-1. Options de cluster de mysqld▲

16-5-5-2. Options de la commande ndbd▲

16-5-5-3. Options de commande pour ndb_mgmd▲

16-5-5-4. Options de commande pour ndb_mgm▲

16-6. Administration de MySQL Cluster▲

16-6-1. Commandes du client de gestion du Cluster▲

16-6-2. Rapport d'événements générés par le cluster MySQL▲

16-6-2-1. Historique des commandes de gestion▲

16-6-2-2. Événements▲

16-6-3. Utilisateur unique du cluster▲

16-6-4. Sauvegarde en ligne de MySQL Cluster▲

16-6-4-1. Sauvegarde du cluster▲

16-6-4-2. Utilisation du serveur de gestion pour une sauvegarde de cluster▲

16-6-4-3. Comment restaurer une sauvegarde du cluster▲

16-6-4-4. Configuration pour la sauvegarde du Cluster▲

16-6-4-5. Résolution de problèmes avec la sauvegarde du cluster▲

16-7. Utilisation d'interconnexions haute vitesse avec MySQL Cluster▲

16-7-1. Configurer le cluster MySQL avec les sockets SCI▲

16-7-2. Mesures de vitesses pour comprendre les impacts sur le cluster▲

16-8. Limitations du cluster dans MySQL 4.1▲

16-9. Cluster MySQL en 5.0 et 5.1▲

16-9-1. Évolutions de MySQL Cluster en MySQL 5.0▲

16-9-2. Plans de développement de MySQL 5.1 pour le cluster MySQL▲

16-10. FAQ MySQL Cluster▲

16-11. MySQL Cluster Glossary▲