MySQL Cluster est dit un cluster « in memory », cela signifie que la plupart des éléments sont, pour des raisons de performance, chargés en mémoire et que ceux-ci sont régulièrement écris sur disque selon divers critères. Il est donc très important que les nœuds de stockage du cluster soient pourvus de beaucoup de mémoire.
Le cluster MySQL ne dispose pas de système de fichier partagé (via SAN, …) comme un cluster au sens « classique » du terme mais dispose d’éléments de dialogue réseau qui lui permet de synchroniser les données du cluster au sein de tous ses nœuds. Les données d’un cluster MySQL sont stockées sur des disques locaux des différents serveurs du cluster et les données partagées sont « répliquées » par des processus internes entre les différentes composantes du cluster.
L’élément fondamental du cluster MySQL est donc la capacité à traiter rapidement et efficacement des requêtes réseau sous le protocole TCP/IP (cartes Ethernets gigabits requises, sockets SCI recommandés).
La documentation indique des options permettent de faire en sorte que le Cluster mySQL écrive sur disque, mais celle-ci sont très consommatrices en ressources et peuvent dégrader de façon significative les performances.
1. Introduction
1.1 Les « nœuds » (ou « nodes ») : composantes de base de MySQL-Cluster
Un élément serveur logiciel élémentaire de mySQL Cluster se nomme un « node » (ou « nœud »). Un node est un élément logique, aussi, il peut exister plusieurs nodes sur une machine physique composante d’un cluster mySQL.
La nature d’un Un node peut être de divers nature :
- Node de STOCKAGE (NDB) :
Le node de stockage (ou node NDB du nom du moteur de cluster « NDBENGINE ») est un nœud chargé de gérer, avec l’ensemble des autres nodes de même nature, la répartition des données sur l’ensemble des nodes de stockage du cluster, d’en assurer la réplication inter-nodes afin de garantir la disponibilité des datas et enfin de gérer les demandes d’accès aux données.
Au vue des forts besoins en mémoire du Cluster mySQL, il est recommandé d’installer des versions 64bits des nœuds NDB afin de passer la barrière fatidique des 3096Go de mémoire maximale sur une 32bits linux.
Dans notre exemple (Cluster « CLUSTER») nous utiliserons 2 nœuds NDB situés en
-
10.20.0.29 (SITSQL01) [ machine physique ]
-
10.20.0.30 (SITSQL02) [ machine physique ]
Les nodes NDB sont au minimum de 2 dans un cluster mySQL.
- Node MANAGER (MGM):
Les nodes MGM (ou « Manager) sont les nœuds du cluster chargés en permanence d’informer les autres nœuds de la configuration du cluster (où sont les nœuds et quelles sont leur nature et leur état, …) et de son rythme de vie (quelles sont les demandes de synchronisations, …)
Dans notre exemple (Cluster « CLUSTER») nous utiliserons 2 nœuds MGM situés en
-
10.20.0.27 [ machine Xen ]
-
10.20.0.28 [ machine Xen ]
Les nodes MGM sont au minimum de 1 dans un cluster mySQL (2 recommandés).
- Node SQL (SQL):
L’accès aux données stoquées sur les nodes NDB ne se fait pas de façon standard, comme pour un serveur mySQL autonome, il faut utiliser un API spécifique dit « NDB API ».
Dans le but de rendre compatible des applications écrites pour des serveurs autonomnes, il faut alors ajouter au cluster des nodes dits « SQL » qui sont des interfaces entre les API clientes standards et les nodes NDB.
Dans notre exemple (Cluster « XXX ») nous utiliserons 2 nœuds MGM situés en
-
10.20.0.25 [ machine Xen ]
-
10.20.0.26 [ machine Xen ]
Les nodes SQL sont au minimum de 1 dans un cluster mySQL (2 recommandés).
Dans une production, un cluster mySQL est donc composé à minima de 6 nodes (2 SQL, 2 MGM, 2 NDB) répartis sur 6 machines différentes dans un souci de haute disponibilité des données et de leur accès.
Notons que le cluster au sens de mySQL ne garanti pas la répartition de charge au sein des nodes SQL, il faudra se munir d’outils annexes (HAProxy, LVS/KeepAlive, etc.) pour cela.
Remarque : Dans le cas du cluster XXXX, voici les adresses contactables :
-
Load balance : sql0.site.fr (serveur à utiliser par les applicatifs)
-
Nœud 1 : sql1.site.fr
-
Nœud 2 : sql12.site.fr
2. Installation
2.1 Introduction
Les méthodes d’installation sont basées sur l’exploitation des outils d’installation disponibles sur une openSuSE 11.3 (x86_64).
2.2 Les packages nécessaires
Sur les nœuds MGM :
- libmysqlclient16
- libmysqlclient_r16
- libmysqlclusterclient16
- libmysqlclusterclient_r16
- libmysqld0
- libqt4-sql-mysql
- mysql-cluster-client
- mysql-cluster-ndb-management
- mysql-cluster-ndb-tools
Sur les nœuds SQL :
- libmysqlclient-devel
- libmysqlclient16
- libmysqlclient_r16
- libmysqlclusterclient16
- libmysqlclusterclient_r16
- libmysqlcppconn-devel
- libmysqlcppconn1
- libmysqld-devel
- libmysqld0
- libqt4-sql-mysql
- mysql-cluster
- mysql-cluster-client
Sur les nœuds NDB :
- libmysqlclient16
- libmysqlclient_r16
- libmysqld0
- libqt4-sql-mysql
- mysql-cluster-ndb-storage
- mysql-cluster-ndb-tools
- mysql-community-server
- mysql-community-server-client
2.3 Fonctionnalités hors distribution
2.3.1 Introduction
Pour une correcte gestion de l’annulation d’un post traitement dans une procédure stockée ou un trigger, nous avons besoin d’ajouter une fonctionnalité supplémentaire livrée la librairie « lib_mysqludf_udf.so » téléchargeable ici : http://www.mysqludf.org/lib_mysqludf_udf/lib_mysqludf_udf_0.0.3.tar.gz.
- Cette librairie est écrite en langage C, il convient d’installer gcc ainsi que les headers mySql (package libmysqlcppconn-devel) pour pouvoir la compiler.
2.3.2 Installation et configuration
1- Compilation
En supposant que les headers mySQl se trouvent dans le répertoire « /usr/include/mysql », voici la commande à lancer pour compiler la librairie :
gcc -shared lib_mysqludf_udf.c -o lib_mysqludf_udf.so -I /usr/include/mysql
2- Installation
Il faut copier la librairie « lib_mysqludf_udf.so » dans le répertoire de partage de mySQL, appelé aussi dossier des « plugins ». Pour connaitre son emplacement, il suffit de se connecter au serveur SQL et de localiser la variable « plugin_dir » en réponse à la commande « show variables ».
Il faudra ensuite créer une fonction SQL utilisant les fonctions de cette librairie en se connectant au serveur mySQL et en tapant :
USE <MABASE>; ç ATTENTION: la fonction est stockée dans la base de données !
CREATE FUNCTION udf_initid_error RETURNS INTEGER SONAME ‘lib_mysqludf_udf.so’;
La fonction « udf_initd_error(message varchar(255)) » est alors disponible dans la database mySQL et permet de provoquer des exceptions afin principalement d’interrompre les traitements des triggers en cas d’erreurs logique.
Remarque : Attention, il faut reproduire l’installation / configuration sur tous les nœuds SQL.
3. Configuration
3.1 Configuration des nœuds SQL
Créer l’arborescence suivante sur chaque nœud SQL :
/data
/data/mysql
/data/mysql/databases
/data/mysql/libs (<= dossier de sauvegarde de l’UDF mysql définie en 2.3)
/data/mysql/run
Indiquer dans le fichier hosts de la machine les mappages nom/adresse des serveurs de managment (2 dans cet exemple) :
Exemple :
10.20.0.27 sql-mgm-01
10.20.0.28 sql-mgm-02
La configuration d’un nœud SQL consiste à renseigner de façon élémentaire /etc/my.cnf comme pour un serveur mySQL autonome, le nœud va charger grâce à cela sa configuration sur l’un des MGM nodes.
/etc/my.cnf :
[client]
port = 3306
socket = /data/mysql/run/mysql.sock
[mysqld]
port = 3306
socket = /data/mysql/run/mysql.sock
datadir = /data/mysql/databases
skip-locking
key_buffer_size = 16M
max_allowed_packet = 1M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
ndbcluster
ndb-connectstring=sql-mgm-01sql-mgm-02
default-storage-engine=ndbcluster
default-table-type=ndbcluster
La commande d’administration sera « rcmysql », voir 4.1.2.
3.2 Configuration des nœuds NDB :
Créer l’arborescence suivante sur chaque nœud NDB :
/data
/data/mysql
/data/mysql/backups (dossier de stockage des backups des réplicas sur ce nœud, voir 5.2)
/data/mysql/datafiles (dossier de stockage des données des réplicas sur ce noeud)
/data/mysql/logs (fichiers de logs pour debugging)
/data/mysql/undofiles (fichiers d’annulation des transactions (rollbacks))
Le fichier /etc/my.cnf contient la définition d’accès aux serveurs de managment pour le nœud NDB :
[mysqld]
port = 3306
socket = /var/run/mysql/mysql.sock
datadir = /data/mysql
skip-locking
key_buffer_size = 16M
max_allowed_packet = 1M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
[MYSQL_CLUSTER]
ndb-connectstring=sql-mgm-01,sql-mgm-02
La commande d’administration sera « rcndbd », voir 4.1.3.
3.3 Configuration des nœuds MGM
Les nœuds MGM propagent la configuration de tous les nœuds du cluster sur l’ensemble des nœuds (SQL et NDB et MGM). Les fichiers de config de ces nœuds sont donc fondamentaux, sont pris en compte lors du démarrage des nœuds MGM. Il est recommandé d’utiliser une configuration de partage globale (SAN, nfs, …) pour que chaque nœud utilise lors de son démarrage et sans ambigüité la configuration n fixée par l’administrateur.
Créer l’arborescence suivante sur chaque nœud MGM :
/data
/data/mysql
/data/mysql/config
/data/mysql/logs
Le démarrage d’un serveur MGM mySQL se fait par la prise en compte d’un fichier de configuration que l’on stoque dans /data/mysql/config/config.ini :
[TCP DEFAULT]
SendBufferMemory=2M
ReceiveBufferMemory=2M
[NDBD DEFAULT]
NoOfReplicas=2
DataMemory=3072M
IndexMemory=3842M
LockPagesInMainMemory=1
[NDB_MGMD]
ID=27
HostName=10.20.0.27
[NDB_MGMD]
ID=28
HostName=10.20.0.28
DataDir=/data/mysql/logs
[NDBD]
ID=29
HostName=10.20.0.29
DataDir=/data/mysql/logs
FileSystemPath=/data/mysql/datafiles
FileSystemPathUndoFiles=/data/mysql/undofiles
BackupDataDir=/data/mysql/backups
[NDBD]
ID=30
HostName=10.20.0.30
DataDir=/data/mysql/logs
FileSystemPath=/data/mysql/datafiles
FileSystemPathUndoFiles=/data/mysql/undofiles
BackupDataDir=/data/mysql/backups
[MYSQLD]
ID=25
HostName=10.20.0.25
[MYSQLD]
ID=26
HostName=10.20.0.26
[MYSQLD]
ID=50
Cette configuration est évidement à adapter en fonction des besoins. Ici nous utilisons deux nœuds SQL, deux nœuds MGM et deux nœuds NDB.
La commande d’administration sera « rcndb_mgmd », voir 4.1.3.
Remarque : Une même et seule version du fichier de configuration « config.ini » doit être présent sur tous les nœuds MGM lors d’un démarrage, pour cela, on peut utiliser la commande :
rcndb_mgmd propage-config
qui propage le fichier config.ini du node MGM sur lequel on est connecté vers tous les autres.
4. Administration
4.1 Options de démarrage des nodes
4.1.1 Noeuds MGM
Ces nœuds sont à démarrer en premier dans le cluster. Sans les nœuds de management démarrés, les autres nœuds (SQL et NDB) risquent de rencontrer des problèmes d’annonce au cluster.
Le lancement et l’arrêt d’un nœud SQL se fait de la même manière que pour un serveur mySQL autonome avec
rcndb_mgmd start : démarre le nœud
stop : stoppe le nœud, arrête tous les nœuds NDB et tous les nœuds MGM
status : indique l’ensemble des nœuds configurés et annoncés au cluster
init : démarre le nœud à l’indentique de « start » mais écrase la configuration binaire pour prendre en compte le fichier /data/mysql/config/config.ini
Différences sur « init » et « start » :
Lors d’un démarrage du nœud en « init », le fichier de configuration textuel est parsé et est fabriqué un fichier de configuration binaire à ses cotés. Le fichier de configuration binaire permet de prendre des modifications de la configuration du cluster de façon dynamique alors qu’il faut relancer les nœuds dans le cadre d’e la prise en compte de config.ini.
Le démarrage en mode « start » ne prend en compte que le fichier de configuration binaire.
4.1.2 Nœuds SQL
Le lancement et l’arrêt d’un nœud SQL se fait de la même manière que pour un serveur mySQL autonome avec
rcmysql start : démarre le nœud
stop : stoppe le nœud
4.1.3 Nœuds NDB
Le lancement et l’arrêt d’un nœud NDB se fait par la commande
rcndbd start : démarre le nœud
stop : stoppe le nœud (ne doit jamais être utilisé, les nodes NDB doivent être arrêtés depuis les nodes MGM, comme indiqué en 4.3.4. Cette option est à utiliser en cas d’urgence seulement, des pertes de données sont possibles alors)
format : DANGER : efface toutes les données du nœud et le démarre (utilisé principalement pour les premiers démarrages et pour certains les recovery)
4.2 Démarrage / Arrêt du Cluster
L’opération d’arrêt / marche du cluster n’est pas anodine et ne doit pas normalement être utilisée, sauf pour des cas extrêmes (maintenance, …), en effet, tous les nœuds vont être stoppés ou lancés, cette opération peut notamment provoquer des pertes de données si elle est effectuée en activité.
L’arrêt et marche du cluster consiste à arrêter / démarrer les nœuds dans un ordre bien précis :
4.2.1 Démarrage :
- Sur MGM-01
rcndb_mgmd init
…
Vérifier avec rcndb_mgmd status (voir 4.3.1)
- Sur MGM-02
rcndb_mgmd init
…
Vérifier avec rcndb_mgmd status (voir 4.3.1)
- Sur NDB-01
rcndbd start
…
Vérifier avec ps ax | grep ndb que deux process ndbd sont présents
- Sur NDB-02
rcndbd start
…
Vérifier avec ps ax | grep ndb que deux process ndbd sont présents
- Sur SQL-01
rcmysql start
…
- Sur SQL-02
rcmysql start
…
Vérifier que tout est OK en se connectant avec un client mySQL sur les frontaux mySQL (password root / mysql) et que, depuis les deux frontaux, on peut accéder aux datas.
4.2.2 Arrêt
- Sur MGM-01 ou MGM-02
rcndb_mgmd stop-all
- Sur SQL-01
rcmysql stop
…
- Sur SQL-02
rcmysql stop
4.2.3 Urgence
En cas d‘urgence seulement, les scripts suivants peuvent aussi êtres utilisés :
- Arrêt : rcndb_mgmd stop-cluster
- Marche : rcndb_mgmd start-cluster (mode init des nodes MGM)
Remarque : L’opération de démarrage de tous les nœuds est rapide, en revanche, la synchronisation inter nœuds ne l’est pas forcément, il ne faudra pas hésiter à attendre plusieurs secondes avant de vérifier l’état du cluster comme indiqué en 4.3.1 et de conclure que cela ne fonctionne pas ou que cela fonctionne.
4.3 Etat du cluster
L’étatdu cluster est consultable depuis un « client » MGM, celui-ci est installé dans nos exemples sur tous les serveurs MGM, il suffit donc, depuis un serveur MGM démarré de taper la commande : ndb_mgm.
Un « shell » de client mgm permet alors de taper divers commandes :
4.3.1 Nœuds connectés et déconnectés
ndb_mgm > show
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=29 @10.20.0.29 (mysql-5.1.41 ndb-7.0.13, Nodegroup: 0, Master)
id=30 @10.20.0.30 (mysql-5.1.41 ndb-7.0.13, Nodegroup: 0)
[ndb_mgmd(MGM)] 2 node(s)
id=27 @10.20.0.27 (mysql-5.1.41 ndb-7.0.13)
id=28 @10.20.0.28 (mysql-5.1.41 ndb-7.0.13)
[mysqld(API)] 3 node(s)
id=25 @10.20.0.25 (mysql-5.1.41 ndb-7.0.13)
id=26 @10.20.0.26 (mysql-5.1.41 ndb-7.0.13)
id=50 (not connected, accepting connect from any host)
Ici nous pouvons observer que 7 nœuds ont été lus dans le fichier de configuration (textuel ou binaire) du serveur de MGM que l’on interroge.
Le nœud n°50 ne s’est pas quant à lui présenté aux serveurs de managment, n’est pas démarré, ou est tombé pour une raison quelconque.
4.3.2 Etat de la mémoire
ndb_mgm > all report memory
Node 29: Data usage is 0%(24 32K pages of total 2560)
Node 29: Index usage is 0%(21 8K pages of total 2336)
Node 30: Data usage is 0%(24 32K pages of total 2560)
Node 30: Index usage is 0%(21 8K pages of total 2336)
Consommation mémoire des différents nœuds. Cette option permet de savoir s’il faut incrémenter les valeurs dataMemory et IndexMemory du fichier de configuration du cluster.
4.3.3 Etat des backups en cours
ndb_mgm> all report BackupStatus
Node 29: Backup not started
Node 30: Backup not started
Lorsque des backups sont en cours d’exécution (voir 5.2), cette commande permet d’observer leur état d’avancement. Ici aucun backup n’est en cours d’exécution.
4.3.4 manipulation des nodes NDB
ndb_mgm> <node_id> STOP
ndb_mgm> <node_id> START
ndb_mgm> <node_id> STATUS
ndb_mgm> ALL STOP
ndb_mgm> ALL START
ndb_mgm> ALL STATUS
5. Sauvegarde et Restauration
5.1 Mode « SINGLE USER »
Le SINGLE USER MODE est utilisé pour restreindre l’accès au cluster à un nœud SQL unique et généralement accessible uniquement par un administrateur et auxquels les applicatifs et/ou les utilisateurs n’ont pas accès, ceci dans le but de faire des opération administratives sans être gêne par les requêtes clientes (restauration, …).
Il faut se connecter sur un nœud MGM et passer la commande :
ndb_mgm –e ‘’ENTER SINGLE USER MODE <ID>’’
(<ID> est le Node-ID d’un nœud SQL administratif (voir fichier de config en 3.3))
Pour revenir à un état normal du cluster, il faut indiquer au serveur de Managment la commande
ndb_mgm –e ‘’EXIT SINGLE USER MODE’’
5.2 Backup base ouverte (« à chaud »)
5.2.1 Introduction
La sauvegarde d’une base sur un cluster mySQL consiste en une opération de sauvegarde des réplicas (données synchronisées inter-nœuds), donc sur chaque nœud NDB, ceci incluant les transactions de base de données en cours (redologs) afin d’assurer l’intégrité des données en cas de restauration.
Une sauvegarde consiste en la création d’un jeu de données sur chaque nœud de stockage NDB. Nous choissons de les stocker dans les dossiers /data/mysql/backups/
La restauration sera une restauration des backups ainsi réalisés sur chaque nœud (un backup d’une database sur n nœuds NDB se restaurera avec une n opérations de restaurations)
5.2.2 Méthode
Pour lancer un backup d’une database, il faut se positionner sur un nœud MGM et utiliser la commande :
rcndb_mgmd backup
Ceci aura pour effet de demander la création d’un backup des métadatas des databases pour chaque nœud NDB et de ranger les « fragments » de backup, su chaque nœuds, dans le répertoire /data/mysql/backups/BACKUP/BACKUP-<Q><HHMMSS>/ où Q est le quantième de la date de déclanchement du backup et HHMMSS l’heure de ce même déclanchement.
Le dossier de backup ainsi créé sur chaque nœud NDB contient :
- *.ctl <= Les fichiers de contrôles
- *.Data <= Les fichiers de données
- *.log <= Les fichiers de transactions pour le recovery des datas après restauration/
5.3 Restauration
5.3.1 Introduction
Comme indiqué en introduction du paragraphe de backup, la restauration d’une database consiste en la restauration de n sauvegardes présentes sur les n nœuds NDB.
5.3.2 Méthode
5.3.2.1 Quelle restauration faut-il effectuer ?
En fonction du type de perte de données et de la volonté de restaurer tout ou partie du cluster ou d ‘une base de données, les « checklist » ne sont pas exactement les mêmes.
Il se distingue globalement trois besoins en matière de restauration de données depuis une sauvegarde :
- CLUSTER (tout est foutu => restauration générale)
- DATABASE (une base de données est HS [ drop database, erreur FS, …], il faut la restaurer
- TABLE [ erreur logique et demande utilisateur ]
Trois besoins, trois méthodes. Au-delà de cela, il faudra réfléchir avant d’agir !
a. Restauration du CLUSTER : Restauration de la totalité du cluster
- Positionner le cluster en « SINGLE USER MODE » (voir 5.1)
- Arrêter le cluster (voir 4.2.2)
- Démarrer tous les nœuds NDB en initialisant des espaces de données
- Sur chaque nœud NDB : rcndbd format
- Restaurer les métadatas (create table, …)
- Sur un des nœuds NDB :
ndb_restore –c <ip MGM> \
–n <ID NDB> –m –b <ID backup> \
–backup_path=/data/mysql/backup/
- Restaurer les datas
- Sur tous les nœuds NDB :
ndb_restore –c <ip MGM> \
–n <ID NDB> –r –b <ID backup> \
–backup_path=/data/mysql/backup/
- Restaurer les objets de base de données (triggers, procédures stockées, …)
- Sur tous les nœuds SQL :
- rcmysql start
- Repérer le dernier dump sql structuel dans le dossier /data/mysql/backup/ et de type « dump_STRUCT_<yyyyy>.sql » puis l’appliquer au serveur avec :
- Sur tous les nœuds SQL :
mysql –uroot < /data/mysql/backup/dump_STRUCT_<yyyyy>.sql
- Sortir le cluster du « SINGLE USER MODE »
b. Restauration d’une base de données : Restauration partielle d’une database ‘DB’
- Positionner le cluster en « SINGLE USER MODE »
- Détruire la database ‘DB’ :
- Sur chaque nœud SQL :
- mysql –uroot -pmysql
- mysql> drop database db ;
- mysql> exit ;
- Sur chaque nœud SQL :
- Restaurer les métadatas de la database (create table, …)
- Sur un des nœuds NDB :
ndb_restore –c <ip MGM> \
–n <ID NDB> –m –b <ID backup> \
–backup_path=/data/mysql/backup/ \
–include-databases=db
- Restaurer les datas
- Sur tous les nœuds NDB :
ndb_restore –c <ip MGM> \
–n <ID NDB> –r –b <ID backup> \
–backup_path=/data/mysql/backup/ \
–include-databases=db
- Restaurer les objets de base de données (triggers, procédures stockées, …)
- Sur tous les nœuds SQL :
- rcmysql start
- Repérer le dernier dump sql structuel de la database ‘db’ dans le dossier /data/mysql/backup/ et de type « dump_STRUCT_ DATABASE_DB_<yyyyy>.sql » puis l’appliquer au serveur avec :
- Sur tous les nœuds SQL :
mysql –uroot < /data/mysql/backup/dump_STRUCT_DATABASE_DB_<yyyyy>.sql
- Sortir le cluster du « SINGLE USER MODE »
c. Restauration d’une table : Restauration d’une table ‘T’ de la database ‘DB’
- Positionner le cluster en « SINGLE USER MODE »
- Détruire la table ‘T’ de la database ‘DB’ :
- Sur chaque nœud SQL :
- mysql –uroot -pmysql
- mysql> drop table db.t ;
- mysql> exit ;
- Sur chaque nœud SQL :
- Restaurer les métadatas de la database (create table, …)
- Sur un des nœuds NDB :
ndb_restore –c <ip MGM> \
–n <ID NDB> –m –b <ID backup> \
–backup_path=/data/mysql/backup/ \
–include-databases=db \
–include-tables=t
- Restaurer les datas
- Sur tous les nœuds NDB :
ndb_restore –c <ip MGM> \
–n <ID NDB> –r –b <ID backup> \
–backup_path=/data/mysql/backup/ \
–include-databases=db \
–include-tables=t
- Sortir le cluster du « SINGLE USER MODE »
5.3.2.2 Syntaxe générale de « ndb_restore »
ATTENTION : Cette commande est à exécuter DEPUIS un nœud de stockage NDB.
ndb_restore
–connect <ip addr> (ou ‘–c’) <= MGM serveur qui pilote la restauration
–restore_meta (ou ‘- m’) <= restaurer les métadatas (DDL)
–nodeid=<node ID> (ou ‘-n’) <= le numéro d’un nœud NDB
–backupid=< backup ID> (ou ‘-b’) <= le numéro du backup (voir 5.2.2)
–rebuild-indexes (ou ‘- r’) <= reconstruction des index
–backup_path=/data/mysql/backup <= le chemin des backups sur les nœuds NDB
[ --include-databases=ma_database ] <= restreindre le backup à cette database
[ --include-tables=table1,table2 ] <= restreindre le backup à ces tables
[ -- print_log ]
6. Considérations pour les développeurs
6.1 Limitations classiques du cluster NDB
Il existe de nombreuses limitations quant à l’utilisation d’un cluster au sens de mySQL, mais la plupart de celles-ci sont exotiques et peuvent être de ce fait contournées facilement.
Les limitations « classiques » sont :
- Limitation de 128 champs par table
- Interdiction d’utiliser des clés étrangères
- Interdiction d’utiliser la création de tables temporaires (temporary tables)
- Pas d’index sur les champs FULLTEXT ou LOB (BLOB, CLOB, …)
- Obligation de créer sur tous les nœuds SQL les déclencheurs, fonctions et procédures stockées (métadatas)
- Interdiction d’utiliser les transactions en SavePoint (plusieurs rollbacks possibles en différents points sur une seule transactions ouverte)
6.2 Problématique liée à l’absence de clés étrangères
L’absence de possibilité d’utiliser les clés étrangères pour une table gérée par le moteur NDBENGINE empêche par définition de s’assurer de l’intégrité référentielle ou de la mise à jour en cascade des données.
Pour pallier à ce manque, il convient d’utiliser des TRIGGERs, principalement AVANT opération DML dans le but d’effectuer manuellement les vérifications d’intégrité référentielle et de provoquer une erreur (voire les fonctions UDF en 2.3) en cas d’anomalie détectée.
ATTENTION : les triggers (comme les fonctions et procédures stockées) ne sont pas des objets dépendants des tables mais de la base de données. Ils ne sont donc pas gérés par les nœuds NDB mais par les nœuds SQL. Aucune propagation de configuration d’un nœud SQL sur un autre n’existe dans cette version du cluster (7.x), il faut donc, sur tous les nœuds SQL, définir les mêmes objets.
6.2.1 Des TRIGGERS pour assurer l’intégrité référentielle
Prenons l’exemple une table TABLEFILLE(IDFILLE, NOM, IDPARENT) qui devrait être liée à une table « mère » TABLEPARENT(IDPARENT, NOM) par le champ IDPARENT.
L’absence de clé étrangère sur ces tables ne permet pas d’assurer l’intégrité référentielle, nous allons utiliser un trigger pour pallier à ce manque.
Voici le trigger permettant de respecter l’intégrité référentielle qu’il faut créer sur tous les nœuds SQL :
DROP TRIGGER IF EXISTS TG_TABLEFILLE_PARENTKEYOK_BI;
DELIMITER |
CREATE TRIGGER TG_TABLEFILLE_PARENTKEYOK_BI BEFORE INSERT ON TABLEFILLE
FOR EACH ROW BEGIN
DECLARE RESULTAT INT;
IF ((SELECT COUNT(*) FROM TABLEPARENT WHERE TABLEPARENT.IDPARENT=new.IDPARENT)=0) THEN
SET RESULTAT=udf_initid_error(« Intégrité référentielle violée sur TABLEFILLE –> TABLEPARENT »);
END IF;
END;
|
DELIMITER ;
6.2.2 Des TRIGGERS pour assurer les mises à jour en cascade
L’absence de clé étrangère sur ces tables ne permet pas d’assurer la mise à jour en cascade des lignes de tables filles lorsque des lignes dépendantes sur une table mère sont supprimées. Nous allons encore une fois utiliser un trigger pour pallier à ce manque.
Reprenons l’exemple des tables TABLEFILLE et TABLEPARENT de 6.2.1.
DROP TRIGGER IF EXISTS TG_TABLEPARENT_DELCASCADE_BD;
DELIMITER |
CREATE TRIGGER TG_TABLEPARENT_DELCASCADE_BD BEFORE DELETE ON TABLEPARENT
FOR EACH ROW BEGIN
DELETE FROM TABLEFILLE WHERE TABLEFILLE.IDPARENT=old.IDPARENT ;
END;
|
DELIMITER ;
6.3 Codes d’erreurs rencontrés
| CODE ERREUR | Explication / Solution |
| 157 | « Could not connect to storage engine »Les noeuds NDB sont arrêtés ou les nœuds MGM sont arrêtes : vérifier et les relancer si besoin |
| 1296 | Impossible de communiquer avec les nœuds NDBFaire un ndm_mgm –e « show » pour vérifier leur statuts, les démarrer au cas ou |
| 1114 | Nombre d’index max. (non PK) atteintð Augmenter la valeur « MaxNoOfOrderedIndexes » + start « init » mode |
| 1005 | Nombre d’attributs max. atteintð Augmenter la valeur de MaxNoOfAttributes + start « init » mode |
| 1478 | Impossible d’indexer un champ CLOB, BLOB, TEXT, FULLTEXT, LONGTEXTð Supprimer l’index ou changer le typage du champ |
| 1089 | Interdiction d’utiliser des préfixes pour les indexes : non supportéð « UNIQUE KEY » devient « KEY », … |
| 1297 | Trop d’opérations simultanéesð Augmenter la valeur de « MaxNoOfConcurrentOperations » + start « init » modeð Augmenter (peut être) la valeur de « MaxNoOfLocalOperations » + start « init » modeCette erreur apparait généralement lors de l’injection de dumps, … |
CopyLeft:
Ces données sont issues d’un document interne de production provenant d’un DataCenter français.