Étiquette : sql

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Administration 5/5

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

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

1. Introduction

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

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

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

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

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

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

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

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

BACKUP-<BackupId>.<NodeId>.ctl 

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

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

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

BACKUP-<BackupId>.<NodeId>.log 

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

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

Meta data

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

Table records

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

Committed log 

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

Utilisation du serveur de gestion pour une sauvegarde de cluster

Il faut suivre les étapes suivantes:

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

[cce]

ndb_mgm> start backup

Waiting for completed, this may take several minutes

Node 3: Backup 1 started from node 1

ndb_mgm> Node 3: Backup 1 started from node 1 completed

StartGCP: 76106 StopGCP: 76109

#Records: 2057 #LogRecords: 0

Data: 51188 bytes Log: 0 bytes

[/cce]

Utilisation du serveur pour annuler une sauvegarde :

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

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

Utilisation des processus serveurs MySQL par MySQL Cluster

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

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

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

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

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

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

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

[cce]

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

[/cce]

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

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

ndb_mgmd, le serveur de management

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

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

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

ndb_mgm, le client de gestion du cluster

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

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

[cce]

shell> ndb_mgm

[/cce]

Commandes du client de gestion du Cluster

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

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

HELP

Affiche les informations sur toutes les commandes disponibles.

SHOW

Affiche les informations sur le statut du cluster.

<id> START

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

<id> STOP

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

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

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

<id> STATUS

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

ENTER SINGLE USER MODE <id> 

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

EXIT SINGLE USER MODE

Quitte le mode d’utilisateur unique.

QUIT

Quitte le client de gestion du cluster.

SHUTDOWN

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

Conclusion

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

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Démarrage 4/5

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

Je rappelle que ce billet est le 4em d’une série de 5 billets:

1. Introduction

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

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

Démarrage du Cluster

Démarrer le cluster n’est pas très difficile une fois qu’il a été configuré. Chaque noeud 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 noeuds dans n’importe quel ordre, il est recommandé de lancer le serveur d’administration en premier, puis les noeuds de stockage et enfin, les noeuds SQL.

Sur l’hôte de gestion, utilisez la commande suivante depuis le Shell pour lancer le processus de gestion :

[cce]

ndb_mgmd -f /var/lib/mysql-cluster/config.ini

[/cce]

Notez que ndb_mgmd doit recevoir le nom et chemin du fichier de configuration, avec l’option -f ou –config-file.

Sur chaque hôte de stockage, exécutez cette commande pour lancer les processus NDBD :

[cce]

ndbd –initial

[/cce]

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 noeud à effacer les fichiers créé par les anciennes instances de ndbd, y compris les fichiers de log.

Sur les hôtes SQL, exécutez une commande mysqld classique (sous simple utilisateur le service ne fonctionne pas si vous êtes en root ) :

[cce]

mysqld &

[/cce]

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 :

[cce]

[root@localhost ~]# ndb_mgm

— NDB Cluster — Management Client —

ndb_mgm> show

Connected to Management Server at: localhost:1186

Cluster Configuration

———————

[ndbd(NDB)] 2 node(s)

id=3 @12.0.1.30 (mysql-5.1.56 ndb-7.1.15, Nodegroup: 0, Master)

id=4 @12.0.1.31 (mysql-5.1.56 ndb-7.1.15, Nodegroup: 0)

[ndb_mgmd(MGM)] 2 node(s)

id=1 @12.0.1.10 (mysql-5.1.56 ndb-7.1.15)

id=2 @12.0.1.11 (mysql-5.1.56 ndb-7.1.15)

[mysqld(API)] 2 node(s)

id=5 @12.0.1.20 (mysql-5.1.56 ndb-7.1.15)

id=6 @12.0.1.21 (mysql-5.1.56 ndb-7.1.15)

[/cce]

Quelques pistes si vous avez des messages d’erreurs

Can’t connect to mysql server through socket ‘/tmp/mysql.sock’

Le serveur MySQL n’est pas lancé.

Le socket précisé lors du lancement du client ne correspond pas à celui du serveur (option –socket pour le client en ligne de commande

Sous UNIX, le user mysql n’a pas les droits sur le répertoire /tmp du serveur.

Access denied for user : ‘xx@xx’ (using password : Y/N)

Le mot de passe entré n’est pas le bon.

Aucun mot de passe n’a été donné alors que le serveur en attend un (option -p du client MySQL en ligne de commande par exemple).

L’utilisateur n’a pas les droits pour se connecter ou sur certaines tables. Pour voir les droits d’un utilisateur, utilisez la commande SHOW GRANTS FOR user@host. Si nécessaire, donnez les privilèges au user (voir plus haut). N’oubliez pas de faire un FLUSH PRIVILEGES pour recharger les droits

L’utilisateur est occulté par un autre plus prioritaire mais aux droits plus restreints. Le serveur MySQL considère d’abord les users les plus spécifiques (avec une adresse IP précise ou « localhost » par exemple) avant de prendre en compte les plus génériques (caractères ‘%’ ou ‘_’ dans le nom du user ou de l’hôte).

Ex : si l’utilisateur Bob se connecte à partir de la machine locale où se trouve le serveur MySQL, les droits de ‘bob@localhost’ primeront, s’ils existent, sur les droits de ‘bob@%’.

Les erreurs d’accès s’expliquent souvent par la présence d’utilisateurs anonymes (user= ») dans la table users qui masquent les droits de certains autres utilisateurs. Pour y remédier, on peut les supprimer par un DELETE FROM mysql.user WHERE user= ».

Connexion failed 1130- Host ‘X’ is not allowed to connect to this MySQL server

Il n’existe aucun utilisateur autorisé à se connecter depuis l’hôte X (dans la table des droits, il n’y a pas de user …@X).

Can’t connect to mysql server on [hôte]

L’option skip-networking du serveur est activée (au démarrage ou dans le fichier de configuration my.ini/my.cnf) et empêche les connexions TCP/IP venant de l’extérieur.

Désactivez également l’option bind-address 127.0.0.1

Arrêter le cluster

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

[cce]

ndb_mgm -e shutdown

[/cce]

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

Pour relancer le cluster, lancez simplement ces commandes :

Sur l’hôte de gestion (12.0.1.10 et 12.0.1.11 dans notre cas) :

[cce]

ndb_mgmd -f /var/lib/mysql-cluster/config.ini

[/cce]

Sur chaque noeud de stockage (12.0.1.30 et 12.0.1.31) :

[cce]

ndbd

[cce]

N’oubliez pas d’invoquer cette commande avec l’option –initial lorque vous redémarrez un noeud NDBD normalement.

Et les hôtes SQL (12.0.1.20 et 12.0.1.21) :

[cce]

mysqld &

[cce]

Suite et fin au prochain épisode !

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Installation 3/5

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

Je rappelle que ce billet est le second d’une série de 5 billets:

1. Introduction

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

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

Il est préférable de télécharger directement les paquets sur le site officiel de MySQL.

Dans notre cas nous utiliserons une distribution CentOS 6.0 avec les paquets RedHat Cluster Suite . On commence donc par téléchargez les paquets suivant :

MySQL-Cluster-gpl-client-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-tools-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-storage-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-shared-7.1.15a-1.rhel5.x86_64.rpm

MSQL-Cluster-gpl-management-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-server-7.1.15a-1.rhel5.x86_64.rpm

On les installe avec la commande suivante:

[cce lang= »bash »]

rpm-ivh mysql-cluster-gpl-*

[/cce]

Je vous conseille de faire l’installation pas à pas. Si jamais lors de l’installation des paquets, vous rencontrez une erreur similaire a celle ci :

Vous devez désinstaller la librairie qui pose soucis . Car elle corrompt les paquets de MySQL-Cluster .

Serveur de management

Dans un premier temps il est préférable de commencer par les serveurs de management, il s’agit de la même configuration sur les deux, avec la même installation de paquet.

Nous devons créer config.ini dans le répertoire /var/lib/mysql-cluster qui permettra le chargement des fichiers de configuration pour le Cluster. On ajoute des directives de configuration suivantes dans le fichier.

[cce lang= »bash »]

# vim /var/lib/mysql-cluster/config.ini

[NDBD DEFAULT]

NoOFReplicas=2

LockPagesInMainMemory=1

DataMemory=4000M

IndexMemory=768M

ODirect=1

NoOfFragmentlogFiles=300

MaxNoOfConcurrentOperations=100000

TimeBetweenGlobalCheckpoints=1000

TimeBetweenEpochs=200

DiskCheckpointSpeed=5M

DiskCheckpointSpeedInRestart=50M

RedoBuffer=16M

MaxNoOfTables=9096

MaxNoOfAttributes=10000

MaxNoOfExecutionthreads=4

MaxNoOfOrderedIndexes=5000

[MYSQLD DEFAULT]

[NDB_MGMD DEFAULT]

[TCP DEFAULT]

SendBufferMemory=8M

ReceiveBufferMemory=8M

[NDB_MGMD]

NodeId=1

HostName=12.0.1.10

[NDB_MGMD]

NodeId=2

HostName=12.0.1.11

[NDBD]

NodeId=3

HostName=12.0.1.30

[NDBD]

NodeId=4

HostName=12.0.1.31

[MYSQLD]

Hostname=12.0.1.20

[MYSQLD]

Hostname=12.0.1.21

[/cce]

Il faut que les deux serveurs de management possède exactement le même fichier de configuration, si vous êtes sous CentOS et que vous n’avez jamais touché a la configuration du parefeu, pensez a le désactiver.

[cce lang= »bash »]

# chkconfig iptables off

[/cce]

Serveurs SQL et serveurs de nœud

Il vous faut installer les mêmes paquets sur ces quatres autres machines, et elles possèdent toutes le même fichier de configuration /etc/my.cnf

[cce lang= »bash »]

# vim /etc/my.cnf

[client]

port=3306

socket=/var/lib/mysql/mysql.sock

[MYSQLD] # Options du processus mysqld

ndbcluster # Fonctionne en mode NDB

ndb-connectstring=12.0.0.100 # Situation du noeud MGM

[MYSQL_CLUSTER] # Options pour le processus ndbd

ndb-connectstring=12.0.0.100 # Situation du noeud MGM

[/cce]

Sur les serveurs SQL pensez a utiliser la commande :

[cce lang= »bash »]

# mysql_secure_installation

[/cce]

Elle permet de donner un mot de passe par défaut a votre serveur SQL, ainsi que l’accès a distance .

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Concept de base 2/5

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

Je rappelle que ce billet est le second d’une série de 5 billets:

1. Introduction

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

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

MySQL Cluster est constitué de trois briques:

  1. Premièrement, un jeu de processus serveurs MySQL. Ce sont des serveurs MySQL traditionnelles, avec le nouveau moteur de table NDBCluster qui autorise l’accès aux tables en cluster.
  2. Le second type de processus est représenté par les noeuds 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 noeuds du cluster, et sont aussi doublées dans le cluster.
  3. Le troisième type de processus est les processus d’administration. Ces processus sont utilisées pour gérer la configuration du cluster.

Nous appelons ces processus de cluster les noeuds du cluster. Mettre en place la configuration du cluster implique la configuration de chaque noeud dans le cluster, et la configuration de chaque moyen de communication entre les noeuds du cluster.

MySQL Cluster est actuellement configuré avec le pré-requis que les noeuds sont homogènes en terme 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.

De plus, il y a un nombre arbitraire de clients connectés au cluster. Ils sont de deux types: ces clients accèdent au serveur de management, et émettent des commandes pour lancer ou arrêter correctement des noeuds, lancer ou arrêter la trace serveur (pour les versions de débogage), pour afficher la configuration courante, voir l’état des noeuds du cluster, afficher les versions et noeuds, lancer les sauvegardes, etc.

Configuration simple-multi serveurs

Nous allons configurer un cluster de deux noeuds, deux serveurs de management, deux LVS en FailOver, et deux serveurs SQL.

 

Naturellement, les machines multi-processeurs et celles aux fréquences supérieures seront plus rapides. Les besoins en RAM des processus du Cluster MySQL sont relativement raisonnables.

Sécurité

Les communications entre les noeuds 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 noeuds 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.

Fonctionnement de cette architecture

Nous avons choisis de virtualiser l’ensemble des serveurs sur Vmware ESXi, cela nous donne une meilleure souplesse quand au changement matériel ( augmentation de RAM / Rajout de carte réseau ) .

Les clients contactent l’application hébergé sur nos serveurs, sur ces serveurs nous inscrivons les adresses des LoadBalancer . Le protocole de routage Round Robin alternera l’envoie des paquets sur les serveurs SQL définis dans sa pool .

Les serveurs SQL ne contiennent pas les données propres a la base de données, ils ne sont la que pour traiter les requètes . A leurs tours ils contactent les Noeuds qui possèdent la totalité de la base de données chargé dans leur RAM.

Les serveurs de management servent a renseigner les serveurs du cluster. C’est lui qui définit les rôles des serveurs . Et répartir la charge automatiquement entre les Noeuds .

L’ensemble des données stocké en RAM sont répliqué entre tous les nœuds, et la charge et partagé entre le nombre de serveurs nœud .

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Tutoriels 1/5

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

La problématique de répartition des données est un problème majeur des infrastructures de gestion de l’information. Alors que l’approche historique consiste à dimensionner un seul serveur de façon à ce qu’il absorbe toute la charge, on observe depuis plusieurs années une tendance inverse, inspirée des techniques de RAID pour les volumes de stockage, qui consiste a prendre un très grand nombre de machines a faible coût pour former un cluster de stockage.

Il existe plusieurs façons différente de mettre en place un Clusteur de Stockage avancé, que je vais vous faire découvrir. Cette série de billet va se focaliser sur la solution MySQL Cluster, la base de données distribuée de MySQL.

 J’installerais MySQL Cluster sur une distribution CentOS, qui peut également être adapter a une distribution RedHat, comme il s’agit de paquet disponible dans les dépôts ReDHat Cluster Suite.

De plus vous trouverez des machines virtuelles sous VMware avec l’ensemble de l’architecture .

Voici le sommaire des 5 billets:

1. Introduction

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

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

On commence de ce pas par le premier article !

Introduction

Dans le domaine des systèmes de gestion de bases de données,MySQL fournit une solution élégante pour réaliser un cluster à faible coût permettant d’atteindre un niveau de disponibilité proche des 99,999% annuel.

 Un Cluster MySQL est un groupe de processus qui s’exécutent sur plusieurs serveurs MySQL, des noeuds 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 noeuds 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 noeud sans autre impact que l’annulation des transactions qui utilisaient ces données.

Elle permet de répartir des données sur plusieurs serveurs sans avoir de point individuel de défaillance. Contrairement aux moteurs MyISAM et InnoDB généralement utilisés avec MySQL, l’exploitation effective du cluster nécessite l’utilisation du moteur NDB, qui contient plusieurs restrictions, comme l’absence d’index FULLTEXT.

 MySQL est capable, depuis la version 4.1 et grâce au moteur de stockage NDB de gérer une grappe de serveurs complète.

  • augmenter la disponibilité
  • faciliter la montée en charge
  • permettre une répartition de la charge
  • faciliter la gestion des ressources (processeur, mémoire vive, disques dur, bande passante réseau).

Sa structure repose sur la duplication données, c’est-à-dire que chaque nœud fera partie d’un groupe de nœud qui posséderont tous la totalité de la base

Un protocole implémenté dans chaque nœud s’occupe d’adresser chaque transaction aux différents nœuds concernés dans la grappe, il faut un minimum de 3 machines pour établir une solution de clustering MySQL et une machine (qui peut elle-même intégrer un serveur MySQL) qui va jouer le rôle de répartiteur de charge en redirigeant les requêtes sur les nœuds disponibles et les moins occupés.

Par rapport à un système de réplication, la redondance est améliorée : si un nœud tombe en panne, sa charge est automatiquement reprise par les autres nœuds.

L’ajout d’un nouveau nœud peut se faire sans avoir besoin de repartitionner la base, il suffit de le faire reconnaître par la grappe et le redémarrage d’un nœud peut se faire sans avoir à redémarrer la grappe.

Du point de vue de MySQL, chaque nœud fait partie d’un ensemble qui pourrait être reconnue comme une seule machine.

Pour le programmeur, il doit programmer son application pour communiquer avec le répartiteur de charge.

Cette solution s’adapte parfaitement lorsque la disponibilité et la sécurité des données est un problème critique et que l’on recherche un partitionnement technique responsable de l’écriture. Couplé a des fonctionnalités temps réel et a une API de programmation asynchrone NDB Cluster s’adresse principalement aux exigences du marché des télécommunications.

Vous pouvez vous rendre sur la page suivante pour voir la liste exhaustive des fonctions proposées dans la version communautaire (gratuite et open-source) de MySQL Cluster.