Cluster MySQL Haute Disponibilité

Cette architecture Haute Disponibilité (HA : High Availability) est composé de 2 serveurs MySQL Manageurs frontaux et de 4 serveurs MySQL Noeuds.
Il est possible d’aller jusqu’à 64 serveurs manageurs et 256 serveurs MySQL.

Schéma

schema

J’ai choisis de présenter cette architecture mais il est bien sur possible d’en utiliser une autre si vous ete limiter au niveau de budget pour le nombre de serveur.
Ainsi, vous pouvez utiliser seulement 2 serveurs de noeuds a la place de 4
De plus, MySQL Cluster etant vrai flexible, il est psosible de faire un cluster MySQL avec uniquement 2 serveurs :
– Un serveur faisant office de manageur mais également noeud et stockage de la base de donnée.
– Un serveur de noeud et stockage.

Egalement, si vous disposer d’un budjet confortable, vous pouvez dedier un serveur pour une seule et unique tache.
Vous aurez donc un serveur manageur, un serveur de noeud, et un serveur de stockage.
Le tout multiplier par le nombre de serveur que vous souaitez tout en n’oubliant pas la limite fixé par MySQL qui est de 64 serveurs manageurs, 64 serveurs de noeud et 64 serveurs de stockage.

Les serveurs frontaux reçoivent les requêtes MySQL, ceux-ci interrogent les serveurs MySQL et envois les données à l’emmeteur de la requête.

Ses deux serveurs manageurs ne seront vu que comme un seule à l’aide d’une adresse IP Virtuelle (IPV).
Cette VIP est générée grâce à l’outil HeartBeat.
Dans notre cas on a un serveur principal (MASTER) et un serveur secondaire (SLAVE).
C’est le serveur en mode MASTER qui « possédera » l’IPV.
HeartBeat permet également de géré le basculement (failover) et re-basculement (failback) entre les deux serveurs.
Ainsi, si le serveurs principal (MASTER) tombe, le secondaire (ESCLAVE) prend le relais, mais si le serveur principal revient, il redevient MASTER.
On répond donc en partie au critère de haute disponibilité.

Ses deux serveurs manageur ne sont pas des serveurs MySQL et ne stockent donc aucune données,
Il est cependant possible que ceux-ci soient également définis comme serveurs MySQL mais cela ne répondrais plus forcement au besoin qui est de proposer une haute disponibilité avec un minimum de sécurité pour les données.

Les serveurs MySQL forment une grappe composée de nœuds (4 serveurs).
Ses 4 serveurs doivent être identiques et donc avoir les même données stocké.
MySQL Cluster permet aux membres de cette grappe d’être identiques.

MySQL Cluster est un système Client/Serveur, le client est une application nommée ndb_mgm et le serveur mysql-ndb.

Lorsque le serveur principal recevra une requête, celui-ci, à l’aide d’un script LUA utilisé par l’application mysql-proxy, interrogera au hasard (Round Robin) l’un des serveurs MySQL de la grappe.
Ainsi, on aura une répartition des charges entre les nœuds de la grappe.

De plus, cette requête qui aura été effectué sur l’un des serveurs sera automatiquement répliqué sur les 3 autres serveurs grâce à MySQL Cluster.

On doit donc avoir 4 serveurs MySQL identiques pour que les données soient les mêmes à chaque passage du « tourniquet » (Round Robin).

Il est possible d’ajouter un serveur MySQL à cette grappe très simplement, celui-ci sera automatiquement mis à niveau en quelques secondes grâces aux autres serveurs de la grappe.

L’installation a été effectué sur des serveurs GNU Linux/Debian ayant avec 512 de RAM pour les serveurs manageur et 256 de RAM pour les serveurs MySQL.
Celle-ci ne nécessite donc pas forcement une grosse configuration et pourtant elle résiste à beaucoup de chose comme je vous l’expliquerais plus bas.
Il est cependant nécessaire d’avoir un « lien de vie » entre le serveurs principal et le serveur secondaire. Ce lien dédié sera uniquement utilisé par HeartBeat pour les échanges entre les deux serveurs manageurs.
Dans mon cas, ce lien a été fait à l’aide d’un câble serial, il est également possible d’utiliser uncable Ethernet RJ45 normal si vous avez une interface restante.

Pour résumer, coté client , vous utilisez uniquement l’adresse IP virtuelle pour effectuer une requêtes SQL.
Les serveurs à l’intérieur du cluster communiquent en utilisant les adresse « réel » des serveurs.

Serveurs Manageurs

Installation des paquets

Si mysql-cluster n’est pas trouvé, vous pouvez le télécharger directement sur le site de MySQL :http://dev.mysql.com/downloads/cluster/

On install MySQL Cluster mais cela va surtout installer le paquet ndb_mgm permettant la gestion du Cluster.
Heartbeat va permettre le basculement et l’adresse IP virtuelle.

Il faut également le paquet mysql-proxy permettant la répartition des charges. Cependant, il est plus compliquer à installer.

Installation et configuration de mysql-proxy

Il est dans un premier temps nécessaire d’installer les dépendances :

Il reste a installer la derniere version de mysql-proxy qui est la plus complete :

wget http://launchpad.net/mysql-proxy/0.8/0.8.1/+download/mysql-proxy-0.8.1.tar.gz
tar-xzvf mysql-proxy-0.8.1.tar.gz
cd mysql-proxy-0.8.1
./autogen.sh
./configure
make
make install

mysql-proxy est donc bien installé et fonctionnel, il n’est malheureusement pas possible pour le moment de faire plus simple…

Configuration de HeartBeat

HeartBeat utilise 3 fichiers de configuration, et ceux-ci sont strictement identiquent sur les deux serveurs.

/etc/ha.d/ha.cf

Dans cet exemple, j’utilise un cable Serial pour le lien de vie, mais vous pouvez utiliser une carte Ethernet :

Sinon pour utiliser le lien de vie avec une carte réseau :

Remplacer :

Par :

Je vous conseille de ne pas passer par une carte réseau existante mais plutôt d’utiliser une 3ème carte réseau.

/etc/ha.d/haresources

Ici, nous définissons le « Maître » au sein du logiciel HeartBeat, c’est-à-dire le serveur qui sera contacté en premier. Nous spécifions également l’IP Virtuelle commune aux deux serveurs manageurs et associée au service mysql-ndb-mgm.
Si le service mysql-ndb-mgm ne répond plus, c’est le serveur esclave (Manager2) qui sera utilisé par défaut avec la même adresse IP Virtuelle.

/etc/ha.d/authkeys

Nous définissions le type de cryptage utilisé lors de la communication entre les deux serveurs manageurs. Il existe trois types de cryptage, MD5, SHA1 et CRC.

Pour valider la configuration :

Configuration de ndb_mgm

ndb_mgm est le services manageant le cluster.

/etc/mysql/ndb_mgmd.cnf

Nous avons choisis de mettre les données sur chaque serveur MySQL qui reçoit ses données. Nous aurions cependant pu stocker les données sur des serveurs différents que sur les serveurs MySQL eux-mêmes. Au sein de notre configuration, nous avons défini comme serveur de stockage ([NDBD]) nos serveurs MySQL ([MYSQLD]).

On à un [MYSQLD] pour chaque serveur MySQL.

/var/lib/mysql-cluster est le répertoire ou sera stocké la base de données concernée par le cluster.
En effet, seul la base de données contenue dans ce répertoire sera répliqué. Vous pouvez donc toujours avoir une base de données locale sur chacun des serveurs et continuer à interroger individuellement chaque serveur sur le base de données locale même si on perd tout l’interet de mettre en place une infrastructure haute disponibilité.

Heartbeat est bien configuré, on à une surveillance du service mysql-ndb-mgm via le lien serial et l’adresse IP Virtuelle (IPV).

Serveurs MySQL (noeuds)

Installation des paquets

Configuration

Indication des serveurs Manageurs

On lui indique les adresse IP des deux serveur manageurs.

/etc/mysql/my.cnf

Si vous en avez plus de deux, il faut toujours les séparer par des virgules.

Création d’une base de données

Importation de tables et d’enregistrements

Il vous faite une migration d’une ancienne architecture MySQL vers cette nouvelle architecture, vous pouvez simplement importer vos tables et enregistrements.

Il faut faire cette derniere manipulation pour chaque table qui sera concerné par la réplication.

Création de tables

Si vous ne partez pas d’une architecture MySQL existante, il vous faut créer vos tables.

On doit utiliser ENGINE=NDBCLUSTER sur chaque table de la base de données afin que celle-ci soit prise en compte au sein de la réplication de la base de données. Sans cette dernière la table ne serait pas prise en compte lors de la réplication.
NDBCLUSTER est simplement un nom que vous pouvez changer, il permet d’identifier un cluster.
Ainsi, vous n’êtes pas dans l’obligation d’utiliser ce parametre si vous ne souhaitez pas qu’une table soit répliquée pour par exemple limiliter la charge sur les serveurs.
De plus, vous pouvez utiliser plusieurs nom pour identifier plusieurs cluster même si je n’en vois pas trop l’utilité.

Nous avons créé une base Nom_De_La_BDD avec une table Nom_Table dont l’utilisateur adminpossède l’intégralité des droits.
L’utilisateur doit être le même sur toutes les machines afin qu’il y ai une bonne interconnexion entre les bases de données lors de la réplication puisque c’est celui-ci qui a les droits de lecture et d’écriture sur les bases de données des différents serveurs.
Afin de configurer les fichiers, nous allons stopper le service MySQL :

Il faut également définir le propriétaire du répertoire /var/lib/mysql-cluster contenant la base de données. On doit donner ce droit à l’utilisateur mysql associé au service mysql du groupe mysql.

Démarrage des services

Sur les serveurs Manageurs

Vous devriez obtenir ce résultat :

ndbmgm

Sur les serveurs MySQL

Répartition des charges (Load Balancing) / Basculement (Failover)

C’est mysql-proxy que nous avons installé précédemment qui va permettre cette répartition des charges.

Celui-ci fonctionne à l’aide de paramètres indiqués à son lancement. Il faut donc créer un script de démarrage pour ne pas à avoir à écrire les paramètres à chaque fois.

Les manipulations sont à faire sur les deux serveurs manageurs.

/etc/init.d/mysqlp.sh

On lui donne les bon droits :

Et on le lance automatiquement au démarrage :

On doit ensuite créer le script .lua permettant la répartition des charge. Celui-ci est un algorythme de type Round Robin.

/etc/mysql/mysql-proxy/script.lua

Le script va utiliser des boucles et faire appel à des variables d’environnement type BACKEND_STATE_DOWN afin de déterminer si le serveur Node est « alive », s’il est down la boucle continue vert le serveur suivant et se connectera à ce dernier s’il est vivant. Une deuxième partie de l’algorithme va permettre d’effectuer une répartition des charges de type « Round-Robin » (Fonction Random / Aléatoire), en effet, il va tenter de choisir aléatoirement les servers afin de ne pas sélectionner toujours le même.

Résultats

On va dans un premier temps pinger l’adresse IP virtuelle :

ping

Afin de déterminer si la plateforme est définitivement fonctionnelle, il suffit d’effectuer des requêtes SQL. En effet, par le biais de la capture ci-dessous, chaque affichage de page fait appel au script LUA définit précédemment qui va gérer le basculement entre les nœuds ainsi que leur répartition des charges (Round-Robin).
Plus concrètement, les termes « Picked backend n° » représentent une tentative de connexion à l’un des nœuds, identifié par son IP ainsi que son numéro. Le statut « done » nous montre que la connexion est effective, et que donc le programme peut fonctionner.

resultat

Test

Coupure d’un serveur manageur

ManageurCut

 

Coupure d’un noeud MySQL

NoeudCut

On va de nouveau effectuer des requêtes SQL :

TestAfterCut

Après tentative de réaffichage de la base de données au sein de l’application web, nous voyons très clairement que la tentative de connexion au nœud n°1 échoue, et qu’automatiquement, il sélectionne un autre nœud (de manière aléatoire par le biais de l’algorithme Round-Robin).
Le serveur n°2 est actif et il se connecte donc dessus afin d’effectuer la requête. Cela aurait pu être n’importe quel autre serveur.

Mise en charge

Plusieurs test de mise en charge ont été effectués avec notamment plus de 200 000 reqêtes SQL SELECT effectués en 1 minutes.
Seule un des serveur à montré quelques faiblesse en plantant un instant et en redemarrant automatiquement son service de Cluster.

En effet, il faut savoir qu’en arriere plan, des services « angel » surveille le bon fonctionnement des services ndb_mgm et mysql-ndb.
Ainsi, si l’un d’eux tombe, il sera automatiquement redémarré.

Interface Web de surveillance

 

Schema_Cluster_Web

Pour ce projet, j’ai réalisé une interfawe web permetant de controller les serveurs et les processus du cluster.
Pour cela, il faut tester les port 3306 (mysqld) sur chaque serveur, sur les serveur manageur le port1186 (mgmd) et sur les noeud le port 2200 (ndb_mgmd).

Lorsque l’on a coupé un serveur noeud, voici le résultat :

node1_deco

Ce projet à été réalisé en partenariat avec Emmanuel Le T.

146 commentaires

  1. J’ai une question toute bête mais si je loue des serveurs sur internet, je peut utiliser des @ip externe dans ce principe ?

    Merci 🙂

  2. Je n’ai jamais testé via internet mais seulement en local mais je ne pense pas que les processus MySQL accepte de communiquer ensemble via Internet…

    Pour le lien de vie HeartBeat qui, dans l’exemple fonctionne avec une connexion Serial, il faudrait modifier pour configurer via une connexion Ethernet (ce qui est pris en charge par HeartBeat).

    Vous pouvez testé mais je ne pense pas que cela fonctionnera…

  3. Merci pour la réponse rapide.

    J’ai trouvé ça :

    Notez que le cluster MySQL n’est pas prévu pour fonctionner sur un réseau avec une connectivité inférieure à 100 megabits. Pour cette raison, entre autres, faire fonctionner un cluster MySQL sur un réseau public ou via Internet risque de ne pas réussier, et n’est pas recommandé.

    Donc à priori c’est quand même possible. Je vais regarder ce que ça donne.

  4. Le problème est que les éléments de larchitecture ne sont pas fait pour communiquer ensemble de manière sécurisé via Internet.

    Seul les deux serveurs manageurs utilisent un lien de vie sécurisé(via HeartBeat) pour communiquer.

    Alors que pour MySQL Cluster, les changements de base de données ne seront pas échangéde manière sécurisé.
    Ainsi, dans un réseau local, via le pare-feu, vous pouvez autoriser seulement les machines à se parler entre elle et donc dire qui a la droit denvoyer des information a qui et qui va écouter quoi et cela permet de cela une zone en quelque sorte sécurisé.

    Alors que sur Internet vous ne contrôler rien donc vous déconseille de le faire surtout si ce sont des informations sensible qui sont échangés.

  5. Bonjour

    J’ai entendu dire que le cluster mySql limite les requetes complexe
    comme jointure de plus de 3 table et sous requete

    est ce vrai ?

    merci

  6. Effectivement, mais avec la nouvelle version de MySQL Cluster 7.2, il n’y a appartement plus ses limitations mais je n’ai pas encore testé.

  7. La procédure d’installation reste identique pour mySQL Cluster 7.2 ?
    ainsi que le schéma ?

    MErci encore pour vos réponse clair et rapide

  8. La procédure d’installation ainsi que le schéma restent les mêmes.

    MySQL Cluster 7.2 apporte seulement plus de stabilité, gère mieux les requêtes complexe et permet de faire plus de requête par minutes.

    Oracle à annoncé 1 Milliard de requêtes SELECT par minutes avec une certaine architecture…

  9. J’ai encore une petite question

    Est ce que je doit suivre ta procédure puis faire un genre de upgrade
    ou alors dois je directement télécharger MySQL cluster des le début ?

    encore merci

  10. Je te conseille de bien suivre la procédure notamment pour MySQL Proxy qui est très chiant à installer…

    Normalement en installant mysql-server il devrait mettre la dernière version de Cluster mais j’installerais tout de même proprement 7.2 qui de toute façon ne changera rien à la suite de la procédure car le fichier de configuration est le même.

  11. Petite erreur je pense a Installation et configuration de mysql-proxy

    sudo apt-get install autoconf automake libtool flex pkgconfig gettext
    libmysqlclient15-dev libreadline5-dev

    ce n’est pas plutot => pkg-config
    ??
    merci

  12. Encore une question (je profite d’utilisé ta méthode 🙂 )

    que veux-tu dire par « modifier » dans le code suivant ?

    cp etc/lua.pc /usr/lib/pkgconfig/
    export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/lib/pkgconfig # A
    modifier
    ACLOCAL_FLAGS= »-I /usr/share/aclocal » # A modifier

  13. Salut a toi

    petite question est ce normale que dans /etc/mysql/ndb_mgmd.cnf
    je ne vois pas mon fichier ndb_mgmd.cnf ?

    sinon tu sais comment dois-je faire pour l’installer.

    Bien à toi

  14. Petits retours suite à ma récente installation :

    – Aucun soucis sur Debian pour un apt-get install mysql-proxy
    – La procédure d’installation de mysql cluster n’est plus du tout la même étant donné qu’il n’est plus intégré à mysql-server.

    Je conseille de suivre le tutoriel officiel de mysql pour l’installation 😉

  15. Bonjour,

    Merci pour votre tutoriel vraiment très clair.

    Par contre ou trouvez vous le paquet mysql-cluster ? Impossible de le
    trouver dans les dépots (Wheezy).

    Y-a-t-il une autre méthode pour installer ce composant ?

    Merci d avance

  16. Ça fonctionne parfaitement 🙂

    Merci pour ce tuto et ce blog plutôt intéressant !!

    ps: certains caractères comme les quotes ne passent pas dans les
    commentaires 😉

  17. Brillant. Merci.
    une question idiote :
    quand je veux simplement ajouter des lignes dans my.cnf

    [mysqld]
    ndbcluster
    ndb-connectstring = 192.168.1.1

    [MYSQL_CLUSTER]
    ndb-connectstring = 192.168.1.1

    Je ne parviens plus à redémarrer mysql ensuite (failed)
    çà remarche si je retire.
    Que puis je mal faire sur si peu de lignes ? 😉

    Merci Chef.

  18. Quel est l’erreur exacte? (à voir dans les logs éventuellement)

    La ligne « ndbcluster » correspond au type de tables (moteur), il sera utilisé avec le « ENGINE=NDBCLUSTER » dans la créations des tables.

    Je ne vois donc pas trop d’où peut venir le problème…

  19. Hello
    merci pour ta réponse rapide !
    truc bizarre : mes fichiers mysql.err ou mysql.log sont vides dans /var/log/
    Concernant ta réponse, il ne faut donc pas écrire textuellement « ndbcluster » comme cela
    à cet endroit ? je pense que si ?

  20. Va plutôt voir dans « /var/lib/mysql-cluster » pout les logs.

    Sinon je te confirme qu’il faut bien écrire directement « ndbcluster » même si ça fait bizarre.

  21. Merci Pierre pour tes réponses rapides. c cool.
    je t’avouerais que j’avais omis de créer le dossier /var/lib/mysql-cluster/
    Je l’ai fait, j’ai redémarré MySQL, le pb persiste et les logs sont vides également…
    vraiment curieux…cette affaire.
    Vraiment merci pour ta réactivité c’est appréciable.
    Bien à toi Chef.

  22. Dans var/lib/mysql
    comme aucun nom de fichier d’erreur est spécifié, j’ai un fichier NomServeur.err
    qui s’est créé : voici le contenu

    error: Wrong group definition in config file: /etc/mysql/my.cnf at line 111
    Fatal error in defaults handling. Program aborted
    120717 23:36:28 [Note] Plugin ‘FEDERATED’ is disabled.
    120717 23:36:28 InnoDB: Initializing buffer pool, size = 8.0M
    120717 23:36:28 InnoDB: Completed initialization of buffer pool
    120717 23:36:28 InnoDB: Started; log sequence number 0 521737336
    120717 23:36:28 [ERROR] /usr/sbin/mysqld: unknown option ‘–ndbcluster’
    120717 23:36:28 [ERROR] Aborting

    120717 23:36:28 InnoDB: Starting shutdown…
    120717 23:36:33 InnoDB: Shutdown completed; log sequence number 0 521737336
    120717 23:36:33 [Note] /usr/sbin/mysqld: Shutdown complete

    120717 23:36:33 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

  23. Sur quel serveur as-tu cette configuration? il faut bien faire la distinction entre les serveurs manageurs et les noeuds.

    Normalement tu dois être sur un noeud.

  24. Excuse pour ma réponse tardive… je finalisé un loadbalancer Glassfish cette fois ! 😉
    elle commence à m’agacer cette erreur débile…
    Oui oui je suis bien sur un noeud.
    j’ai mis dans my.cnf

    ndbcluster
    ndb-connectstring = 192.168.1.1
    sous cette référence [mysqld] déjà existante (tout à la fin de cette section)

    et juste après j’ai mis çà, tel quel :

    [MYSQL_CLUSTER]
    ndb-connectstring = 192.168.1.1

    Merci pour le temps que tu consacres.

  25. J'ai quand même vérifié de mon coté et il n'y a aucun changement avec la dernière version de MySQL Cluster (7.2) sur les fichiers de configuration et le « ndbcluster » est toujours bien présent.

    Il n'y a pas un espace qui traine avant ou après « ndbcluster » ou quelque chose du genre qui pourrait gêner lÂ’interprétation de la config?

    Quel version de MySQL as-tu? Apparement dans la version 5.1, ndbcluster n'est pas supporté : http://bugs.mysql.com/bug.php?id=36193

    Je pense que c'est à cause de ça 🙂

  26. mysql –version

    mysql Ver 14.14 Distrib 5.1.63, for debian-linux-gnu (x86_64) using readline 6.1

    ce serait donc çà … ? – je pensais que j’avais la dernière version stable en installant avec
    apt-get install mysql-server

    merci encore Pierre, t’assures.

  27. Via yum on me propose directement la mysql-server-5.5.25a-1.fc17.x86_64 donc c’est bizarre.

    Confirme moi qu’une version plus récente fonctionne pour que je le précise dans le tuto.

  28. Thanks for the quick answer again.

    je regarde çà cet aprem en effet et te tien évidemment au courant…
    tu pourrait me dire le contenu de ton fichier /etc/apt/sources.list
    si toutefois yum l’utilise car une commande rapide du style :

    sudo yum install mysql-server
    me sort qu’il n’y a pas de paquet …

    Configuration du processus d’installation
    Aucun paquet mysql-server disponible.
    Rien à faire

    Il a décidé de m’embêter je crois…;-)
    @ tout’

  29. suite :
    bon bah j’ai réussi installer mysql-server 5.5 via apt-get en ajoutant des paquets à
    mon fichier sources.list
    bonne nouvelle ou pas, le problème demeure… incroyable.
    /etc/init.d/mysql restart
    Stopping MySQL database server: mysqld.
    Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
    aucun fichier d’erreur dans /var/lib/mysql-cluster

    trop fort. ;-(

    Je finirais bien par trouver, certainement une connerie qui traîne comme souvent…
    j’ai toutefois bien regardé les espaces, j’ai enlevé les Majuscules au cas où, enlever mes
    commentaires…

  30. Chef,
    Ce genre te config te parait il bon :

    [NDBD DEFAULT]
    NoOfReplicas=2 # Nombre de n½uds NDB
    DataMemory=1664MB
    IndexMemory=256MB
    DataDir= /var/lib/mysql-cluster
    MaxNoOfConcurrentOperations=10000
    MaxNoOfOrderedIndexes=512
    MaxNoOfUniqueHashIndexes=256
    MaxNoOfTables=256
    MaxNoOfAttributes=1500

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

    [NDB_MGMD]
    nodeid=1
    HostName=192.168.1.1 # VM debian605 Avec son adresse IP locale

    #[NDB_MGMD]
    #HostName=192.168.1.3
    #en attendant le second manager …

    [NDBD]
    nodeid=2
    HostName=192.168.1.2
    DataDir= /var/lib/mysql-cluster

    [NDBD]
    nodeid=3
    HostName=192.168.1.3
    DataDir=/var/lib/mysql-cluster

    #[NDBD]
    #HostName=192.168.102.63
    #DataDir=/var/lib/mysql-cluster

    [MYSQLD]
    nodeid=4
    HostName=192.168.1.2
    [MYSQLD]
    nodeid=5
    HostName=192.168.1.3

    pourquoi les noeuds 4 et 5 ne sont pas en fait 2 et 3 puisque ce sont les mêmes
    machines

  31. Je t’avouerais que j’ai fait çà par ce que j’ai eu ce message au démarrage du cluster :
    ndb_mgmd –configdir=/var/lib/mysql-cluster

    MySQL Cluster Management Server mysql-5.5.22 ndb-7.2.6
    2012-07-19 17:12:15 [MgmtSrvr] ERROR — Could not determine which nodeid to use
    for this node. Specify it with –ndb-nodeid= on command line

  32. Bonsoir,
    Pierre ôte moi d’un soudain doute :
    sur mon manager : j’installe bien mysql-cluster7.2 uniquement ? (cas d’un unique
    manager tout d’abord)
    sur mes noeuds : j’installe bien mysql-server-5.5 uniquement ?

  33. Tout fonctionne très bien. J’ai tout recommencé sur mes 3 VM représentant 1 manager et
    2 noeuds (sous VMWARE, nickel pour les tests)
    En fait j’ai installé mysq-cluster7.2 sur les 3 machines avec des configs différentes selon
    manager ou noeud.
    MERCI pour ta dispo et ton article en tous cas.
    J’ai envie de me tester le loadbalancing désormais.
    Je me faire une nouvelle VM.
    @+

  34. hello
    I’m back
    dis moi, configure t on le /etc/ha.d/ha.cf avec une connexion réseau entre les 2 et pas
    série…?

    tout se passe entre mes 4 VM sur un même serveur physique pour moi…
    leur adresse :
    192.168.1.1 et 192.168.1.4 pour mes managers qui doivent communiquer entre avec
    donc le lien heartbeat
    192.168.1.2 et 192.168.1.3 pour mes noeuds SQL

    Tout fonctionne nickel pour le moment comme çà.
    Peut on utiliser le même port réseau pour faire la connection Heartbeat…? j’ai peur…

    Merci

  35. Je travaillais également sur des VM pour faire ce Cluster.

    Pour ce qui est de la connexion entre les deux serveur manager pour le loadbalancing, il y a deux possibilité: Serial ou Ethernet.

    Dans mon exemple je montre avec un cable Serial mais si tu veux le faire en Ethernet, la configuration sera différente dans le fichier /etc/ha.d/ha.cf sans le « serial » « baud » etc…

    Tu peux utiliser le même pour pour Heartbeat il me semble mais je te le conseille pas trop car le lien de vie va transiter sur ton réseau…normalement de facon sécurisé…mais bon. Autant privilégier un lien direct entre les serveurs, il n'y aura aucun autre éléments perturbateur pour géner les communications entre eux.

    Deja que ce sont des serveurs frontaux qui vont recevoir toute les requêtes, même si ils ne les traitent pas, le nombre de connexion sur les serveurs va quand même être déjà très important, alors en rajouter… (1 par seconde en plus).

  36. Merci Pierre.
    C’était le sens de ma question. Que mets à la place de serial et baud ?
    en les enlevant simplement j’avais un vieux message d’erreur : (ptet pas la cause) 😉

    Stopping High-Availability services: Heartbeat failure [rc=127]. Failed.
    Waiting to allow resource takeover to complete:sleep: invalid time interval //'
    sleep: invalid time interval
    Temps’
    sleep: invalid time interval avant'
    sleep: invalid time interval
    de’
    sleep: invalid time interval d303251clarer'
    sleep: invalid time interval
    un’
    sleep: invalid time interval serveur'
    sleep: invalid time interval
    comme’
    sleep: invalid time interval mort'
    Try
    sleep –help’ for more information.
    Done.
    Starting High-Availability services: IPaddr[1216]: INFO: Resource is stopped
    Heartbeat failure [rc=127]. Failed.
    /usr/lib/heartbeat/heartbeat: symbol lookup error: /usr/lib/libpils.so.2: undefined
    symbol: g_malloc_n

    Pour mon lien de vie, je peux certainement créer une 3ème carte réseau sur mes VM

  37. L'erreur vient du faite que tu as laissé les commentaires avec les « // ».

    Sinon pour utiliser le lien de vie avec une carte réseau :

    udpport 694
    udp ethX

  38. Merci Pierre.
    comme je suis sur VM également, je peux utiliser le lien serial.
    Il n’y a rien de particulier à faire ou fait il préciser des choses dans les paramètrages de
    mes VM pour stipuler un lien serial ?
    Bien à toi.

  39. Au niveau des VMs même, il faut créer un cable Serial, ensuite au niveau du système, il faut activer le cable Serial et tester la communication entre les serveurs en envoyant des message via le port et voir si de l'autre coté on le reçois bien.

    La création du port serial sur les VMs c'est une sorte de Client/Serveur :

    # à faire sur VMware une machine
    VM >> Settings
    Cliquer sur « Add »
    Choirir « Serial Port »
    Cocher « Output to named pipe »
    Nom du port : .pipecom_1 ## 2 antislash avant le . et avant "com"
    Type de machine : « This end is the server »
    Type de l'autre machine : « The other end is a Virtual Machine »

    # à faire sur VMware l'autre machine
    VM >> Settings
    Cliquer sur « Add »
    Choirir « Serial Port »
    Cocher « Output to named pipe »
    Nom du port : .pipecom_1 ## 2 antislash avant le . et avant "com"
    Type de machine : « This end is the client»
    Type de l'autre machine : « The other end is a Virtual Machine »

    # à faire sur le système des deux machines
    – sudo apt-get install minicom
    – dmesg | grep ttyS
    – on note le port serial (ttySX), si plusieurs, tester les deux par la suite

    # à faire sur un serveur (qui va recevoir un message de test)
    – cat < /dev/ttySX
    – attendre le message

    # à faire sur l&#039;autre serveur (qui va envoyer un message de test)
    – echo "test message" > /dev/ttySX

    Si le le message s&#039;affiche sur le premier serveur c&#039;est bon.

    A tester dans les 2 sens pour avoir les deux nom ttySX, généralement X egale 0 ou 1.

    Une fois que tu a les deux nom ttySX, tu peux bien les renseigner dans Heartbeat.

  40. mysql-proxy est à installer sur les deux servers manageurs, les deux serveurs manageurs peuvent recevoir des requêtes.
    c’est ensuite heartbeat via l’adresse IP virtuelle qui désigne le serveur.

  41. merci encore et toujours Pierre.
    finalement je n’ai pas fait de lien serial mais ethernet (un nouveau).
    2 petites questions :
    1.

    dans mysql-proxy tu parles de username/password :
    –admin-username=’manager’
    –admin-password=’root’
    c’est ceux de MySQL ou d’autres juste pour çà ?

    2.l’IP virtuelle dans /etc/ha.d/haresources on met vraiment ce que l’on veut ?
    je suis en local entre mes 4 VM sur un réseau : 192.168.1.0
    et mon lien heartbeat est en 192.168.2.0
    j’ai testé une IP en 192.168.2.50 et 192.168.1.50 je n’ai jamais réussi à pinger depuis
    manager1

    MERCI

  42. Le username et password c’est juste pour mysql-proxy et pas forcement obligatoire il me semble.

    Sinon pour l’adrese IP virtuelle, elle doit être dans le même réseau que les serveurs manageurs, je n’ai jamais eu aucun problème la dessus.

  43. Merci Pierre.
    mais j’essayais de suivre ce que tu nous écrivais plus haut dans ton exemple :
    /etc/ha.d/haresources :
    Manager1 192.168.102.50 mysql-ndb-mgm
     »
    Ici, nous définissons le « Maître » au sein du logiciel HeartBeat, c’est-à-dire le serveur
    qui sera contacté en premier. Nous spécifions également l’IP Virtuelle commune aux
    deux serveurs manageurs et associée au service mysql-ndb-mgm.
    Si le service mysql-ndb-mgm ne répond plus, c’est le serveur esclave (Manager2) qui
    sera utilisé par défaut avec la même adresse IP Virtuelle.  »

    —-

    Sinon,quand tu fais une modif des 3 fichiers utilisés par hearbeat (que donc tu
    répercutes sur le second manager)
    doit tu « restarter » obligatoirement heartbeat sur les 2 serveurs ou le « lien » entre les 2
    (serial ou autre) fait ce qu’il faut ?

    MERCI.

  44. Coucou Pierre
    en plus de ma petite question ci desssous, je voudrais savoir si tu connais une manip
    SQL pour faire un alter table général pour passer les 65 tables de ma BDD dans mon
    cluster (pour ajouter dbengine = ndbcluster)
    ce serait nice ! 😉

    Bien à toi
    merci pour tout.

  45. Si tu fais des modifications d'un ou plusieurs fichiers de configuration de Heartbeat, il faut les faires sur les deux serveurs à l'identique et redémarrer Heartbeat à chaque fois pour bien prendre en compte les modification car Heartbeat charge les fichiers de config quand il démarre.

    Je ne suis pas certain qu'il soit possible de changer toute les tables d'un seul coup, ou alors en modifiant directement TABLE_SCHEMA, il doit y avoir des manip sur Google.
    Je te conseille de faire une sauvegarde de ta base avant…

    Je pars en vacances demain donc c'est normal si je répond plus pendant un moment sauf si je trouve un Wifi 🙂

  46. cool que tu partes en vacances.
    ptet ma dernière question alors 😉
    un peu con alors.
    comment tu testes tes requetes sql avec l’IPV dans cette architecture.
    j’ai mes 2 managers, mes 2 nodes, soit 4 VM Debian sur mon serveur physique.
    comment tu testes en fait ? de où ?
    je dois être un peu fatigué là… 😉 je pense que ma question est con ..

    MERCI et bonnes vacances à toi.

  47. Je pense qu’il ne faut pas indiquer tes fichiers de configuration dans Heartbet : « debian605 192.168.1.50 ndb_mgmd »

    C’est un service qui est renseigné pour voir si il tourne, Je ne pense pas que heartbeat soit fait pour relancer un service.

    Ducoup, si tu souhaite relancer un service down, un petit coup de script avec un crontab chaque seconde.

  48. Hier…

    Pour tester les requetes SQL, il faut définir sur l'application qui doit se connecter à la base de données, le serveur MySQL, qui est accessible via l'IPV.

  49. Salut Chef,
    J’espère que tu vas bien..
    Je reprends un peu mes clusters BDD en ce moment… je fais juste des petites créations
    de BDD, tables simplissimes entre mes 2 noeuds…et j’ai sans arrêt ce message et mes
    query ne se finissent pas :

    ERROR 2013 (HY000): Lost connection to MySQL server during query

    très curieux. Je trouve tout et n’importe quoi sur le Web
    déjà vu çà ?

    Merci de ton aide.

  50. Salut,

    Jamais vu ce genre d’erreur, quand tu fais tes tables tu met bien « ENGINE=NDBCLUSTER » ? sinon c’est pas pris en compte dans le Cluster.

    Que disent les logs?

    J’ai regardé les reponses données et effectivement ca va d’un probleme innodb à /etc/hosts.allow…ce dernier a l’air de pas mal sortir.

  51. thx Pierre..
    c’était peut être mon « iptables » trop strict…
    curieux mais bon…car il me semble que çà marchait bien avec les mêmes règles avant
    et que rien n’a changé depuis …. Bref, les mystères de l’informatique, on va dire… 😉

    Figure toi que je ne sais toujours pas comment configurer application Java (sur serveur
    d’app Glassfish – qui est sur un de mes 2 nodes avec data – ) avec la fameuse IPV …;-)
    référençant mes 2 managers…
    La réplication se fait bien entre les 2 data nodes mais je ne sais pas si Hearbeat
    fonctionne bien … 😉

    thx for all

  52. Si je fais ce genre de requête sur un des mes serveur de mon cluster (data or manager)
    çà devrait me sortir qqch si tout est OK (heartbeat,cluster etc…) non ?

    mysql -u ‘user’ -p’pasword’ -h 192.168.1.50

    avec 192.168.1.50 mon IPV
    192.168.1.1 et 192.168.1.2 mes managers
    192.168.1.3 et 192.168.1.4 mes data nodes

    Mais j’obtiens assez logiquement :
    ERROR 2003 (HY000): Can’t connect to MySQL server on ‘192.168.1.50’ (111)

    cheers,

  53. A partir du moment ou tu arrives à pinger ton IPV, c’est que celle-ci est bien créé et donc que Heartbeat est bien configuré et fait son boulot.

    Si tu n’arrive pas à l’indiquer dans ton appli Java, c’est un autre problème, peut être comme avant avec des pare-feu trop restrictif.

  54. Merci.
    donc d’après toi, je dois être capable de faire la commande SQL que je décris ci dessus.
    puisque je PING tout bien comme il faut…

    A bientôt.

  55. Bonjour,

    Je viens de lire votre article très intéressant.

    On avait mis à ma disposition un « cluster » de deux serveurs (donc je
    suppose ne correspondant pas à votre schéma) sous le nom de « master-
    master ». Pensez-vous que cela corresponde à ce que vous nommez
    « cluster » ? ou bien est-ce un autre mode de mysql ?

    Avec ce mode master-master, j’ai rencontré des difficultés suites à
    des redémarrage « électrique ». Au redémarrage les réplications
    « croisées » étaient incohérentes, ce qui m’a fait revenir à un mode
    plus stable master-slave. (Il y avait beaucoup d’activité d’écriture
    lors de l’incident)

    Votre architecture est-elle bien tolérante en cas de défaillance
    « électrique » ?

    Cordialement

  56. Bonjour,

    Le mode master-master ne correspond pas à l'architecture que je présente et n'utilise pas les mêmes services et n'est pas un cluster.

    Le mode master-master permet en cas de crash de l'un des serveurs de basculer sur l'autre qui est identique et de pouvoir revenir sur le premier facilement car ceux-ci sont identiques et se répliquent entre eux.
    Il y a des échanges de données dans les deux sens, si des données sur écrites sur l'un elle sont également répliquées sur l'autre et inversement.

    Au contraire pour le master-slave, les données sont répliquées
    uniquement du master vers le slave et non inversement.
    Ainsi, si le master crash, le slave prend le relais, mais les données ne seront pas répliquées sur le master-ci celui-ci revient par la suite.

    Ayant testé une architecture master/slave puis master/master avant de partir sur le cluster, les deux première architecture ne sont franchement pas facile à mettre en œuvre, et ne gère pas bien les crash de serveur, la preuve avec votre exemple.

    L'idée avec ce cluster, est qu'il est possible de faire de la répartition de charge sur plusieurs serveurs, notamment lorsqu'il y a beaucoup de lectures et d'écriture.

    Également, la gestion des crash sur les serveurs, surtout sur les serveurs nœuds (les 4 du schéma) est super bien géré, car pour intégré un serveur dans les cluster c'est super simple et il se met à niveau automatiquement grâce aux autres nœuds.

    Ainsi, vous pouvez avoir 3 cluster qui crash sur les 4, pour mettre un nouveau serveur, il suffit juste d'éditer le fichier de configuration, de redémarrer le service et il récupère toutes les données automatiquement..

    Ici je parle de crash serveur, mais si c'est simplement le service de nœuds crash, il y a un service qui surveille ce service et le redémarre automatiquement.

    Donc effectivement avec le cluster la gestion des crash est mieux géré car nécessite une petit configuration pour remettre en route, avec qu'avec les autres architecture c'est bien plus long et chiant à remettre en œuvre.

    Si actuellement vous êtes sur du master-slave ou master-master et que vous craignez les crash, je vous conseille de passer sur du cluster.

    De plus, le schéma que j'utilise peut être différent car vous pouvez mettre les services des serveurs 2 manageurs sur par exemple 2 serveur nœuds et ainsi utiliser moins de serveur mais le fait de gérer plusieurs service sur un même serveur n'est jamais vraiment bien.

    Je précise que vous pouvez très bien avoir seulement 2 nœuds au lieu des 4 qui sont sur mon exemple.

    Et pour les coupures électrique, avec du master-slave ou master-master, vous aller bien galérer a tout remettre en place et avec les bonnes données.

    Avec le Cluster, vous redémarrer les service, les serveur se remettrons automatiquement à niveau tout seul après redémarrage des services.

    De toute façon avec une tel architecture et même pour la gestion de la base de données il est impératif d'avoir un onduleur derrière, voir une sauvegarde sur NAS ou bande.

  57. Salut Pierre. La forme ?
    as tu déjà rencontré le pb (ERROR 1114 (HY000) at line 150: The table ‘nom_table’ is
    full
    ) décrit ici :

    question :
    http://forums.mysql.com/read.php?25,226318,226318#msg-226318
    réponse :
    http://forums.mysql.com/read.php?25,226318,227119#msg-227119

    j’y suis aujourd’hui confronté à travers mes tests alors que je faisais juste un IMPORT
    de 280Mo soit 4millions de lignes.

    Mon application pro est destinée à beaucoup plus.
    C’est super important en fait.

    Merci de ton aide/avis là dessus.

  58. Salut,

    Je n’ai jamais eu le problème car la base n’était pas aussi importante.

    D’après la reponse qui est donnée, le problème viendrait donc de la mémoire RAM et/ou données donc il faudrait voir sur le fichier my.cnf sur les serveur manageurs et/ou noeuds ou il est définis la RAM aloué et le l’espace disque aloué.

    Ayant été confronté dernierement un une optimisation d’une base de données MySQL, j’ai été amené à chercher comment l’optimiser, a augmenter des paramettre qui pouvais être trop bas par default par exemple.

    Par exemple ce site (http://www.justin.my/2011/04/optimizing-my-cnf-in-new-server/ ) qui presente les différents parametres de my.cnf pouvant être utilisé.

    Pour ton problème, je pencherais pour un tmp_table_size ou table_cache trop bas et donc une table full… je me trompe peu être mais il faut creuser la chose.

  59. Hello. J’avais en effet modifié qques params en attendant ta réponse mais sans succès.
    Je vais creuser avec ton lien. MERCI.
    Un autre pb (qui semble non résolu à ce jour) au sujet des tables dans un cluster est
    l’utilisation « impossible » de FOREIGN_KEY.
    C’est très con, mais surtout problématique, ce truc là non ? 😉

    Merci pour ta réactivité, c’est vraiment top.

  60. Je suppose que le moteur que tu utilise actuellement est MyISAM car c’est celui utilisé par défaut sur MySQL, et MyISAM de supporte pas l’intégrité référentiel (FOREIGN_KEY…).

    Tu peux convertir ta/tes base(s) en InnoDB qui lui le supporte, il faut faire attention car InnoDB ne support pas lui même certain choses du genre l’indexation FULLTEXT…

    Je te conseil de sauvegarder ta base avant de faire quoi que ce soit.

  61. Merci Pierre.
    Mais qqch m’échappe tout à coup : pour utiliser mes tables dans le cluster, il me faut
    préciser : ENGINE=NDBCLUSTER
    en remplacement de MyISAM ou autre INNODB
    c’est le but de la manip
    Et c’est avec cette précision de moteur que le pb se pose.

  62. Effectivement :’), j’ai tendance à ne plus voir ndbcluster comme un moteur.

    Apparement ndbcluster ne gere pas l’intégrité référentiel (bon a savoir…), il va donc falloir supprimer les parametres FOREIGN_KEY de tes tables, il faudra cependant faire attention à tout de même concerver une certaine logique et organisation dans tes tables par la suite sans forcement avoir de parametres FOREIGN_KEY.

  63. C’est super bizarre que ce pb se soit pas résolu.
    C’est important dans une organisation (et pour optimiser les requêtes) d’avoir des
    Foreign Key. J’ai vraiment du mal à comprendre ce manque. ;-(

    Merci pour tes réponses Chef. Bon dimanche.

  64. hello
    juste pour être sûr. j’ai 2 VM managers et 2 VM data différents des 2 premiers.
    les paramètres que je modifie (pour la taille des tables par ex. etc..) c’est bien sur
    les managers que çà se gère ? et moi c’est dans les fichiers suivants :
    /var/lib/mysql-cluster/config.ini

    c’est pas dans les my.cnf des noeuds, si ?

    merci.

  65. Merci, oui c’est logique. sorry.
    Je suis toujours à la recherche d’une solution pour la volumétrie dans le cluster.
    J’ai changé pas mal de param à la hausse, j’ai ajouté –big-tables dans [mysqld] mais
    rien n’y fait du tout. J’ai même ajouté un MAX_ROWS à 4200000000 dans le CREATE.
    Je note que lors de la création, si je mets ENGINE = InnoDB, çà passe sans pb
    mais si je mets engine = NDBCLUSTER, j’ai table full au bout de quelques secondes.
    Je ne trouve pas de nouvelles idées sur le web.

    un ex de my.cnf ici :
    [client]
    port = 3306
    socket = /tmp/mysql.sock
    [mysqld]
    port = 3306
    socket = /tmp/mysql.sock
    skip-external-locking
    tmp_table_size=16777216
    table_cache=2048
    big-tables
    optimizer_switch=engine_condition_pushdown=off
    ndbcluster # run NDB storage engine
    ndb-connectstring=192.168.1.1,192.168.1.4 # location of management server
    [mysql_cluster]
    ndb-connectstring=192.168.1.1,192.168.1.4 # location of management server

    ici un config.ini d’un manager :

    [ndbd default]
    NoOfReplicas=2
    DataMemory=6G // j’ai essayé avec des Mégas aussi
    IndexMemory=2G
    #FragmentLogFileSize=16M
    NoOfFragmentLogFiles=200
    #UndoIndexBuffer=10M
    #RedoBuffer=256M
    MaxNoOfConcurrentOperations=100000
    #NoOfDiskPagesToDiskAfterRestartTUP=150
    #NoOfDiskPagesToDiskAfterRestartACC=83
    #Diskcheckpointspeed=10M
    #Diskcheckpointspeedinrestart=100M
    TimeBetweenGlobalCheckpoints=1000
    TimeBetweenLocalCheckpoints=3
    TimeBetweenWatchDogCheck= 30000
    MaxNoOfTables=4096
    MaxNoOfAttributes=24756
    MaxNoOfOrderedIndexes=2048
    MaxNoOfUniqueHashIndexes=512

    [tcp default]

    [ndb_mgmd]

    hostname=192.168.1.1 # Hostname or IP address of MGM node
    datadir=/var/lib/mysql-cluster # Directory for MGM node log files

    [ndb_mgmd]

    hostname=192.168.1.4 # Hostname or IP address of the second MGM node
    datadir=/var/lib/mysql-cluster # Directory for MGM node log files

    [ndbd]

    hostname=192.168.1.2 # Hostname or IP address
    datadir=/usr/local/mysql/data # Directory for this data node’s data files

    [ndbd]

    hostname=192.168.1.3 # Hostname or IP address
    datadir=/usr/local/mysql/data # Directory for this data node’s data files

  66. Je vient de tomber sur ça : http://forums.mysql.com/read.php?25,264288,264457#msg-264457

    Apparement, les modifications de config n’était pas bien prise en compte et le resultat est plus que correcte en passant de 90% de RAM/Disque à 5-7% en redemarrant les service et spécifiant les bon fichiers de conf.

    Il faudrait refaire la manip plusieurs fois en vérifiant bien ta conf et notamment les paramettres Data et Memory, si il doivent être en Mo ou Go (Apparement le Mo ressort le plus souvent).

    Si avec tes changements de paramettres, il ne t’affiche même jamais d’erreur sur une mauvaise manip sur le fichier, je pense plus a un problème de location du fichier conf comme expliqué plus haut et donc ne voit peu être jamais les modif effectué sur le fichier de conf.

    MySQL Cluster est fait pour fonctionner avec de grosse tables donc je ne pense pas que qu’il soit limité aussi facilement.

  67. coucou
    j’ai parcouru le web toute la journée donc j’étais tombé dessus.
    j’ai tout refait plein de fois et en effet mes param ne semblent pas pris en compte mais
    je sais pas pourquoi. Pourtant si je fais une erreur grossière dans mon fichier de
    config.ini
    il la voit bien donc il charge bien le fichier que je souhaite…
    ça me rend fou ce genre de truc…
    J’espère que ce n’est pas parce que j’ai 2 managers, car je dois normalement tout faire
    exactement de manière identique sur les 2 serveurs.

    Je fais çà sur mes managers :
    ndb_mgmd -f /var/lib/mysql-cluster/config.ini –configdir=/var/lib/mysql-cluster —
    reload

    et çà sur mes noeuds

    /usr/local/mysql/bin/ndbd
    et un restart mysql

  68. hello,
    question concernant Heartbeat : qd je redémarre le service sur les managers, j’ai ce
    message d’info (certes) mais curieux : « Resource is stopped » ??

    /etc/init.d/heartbeat restart
    Stopping High-Availability services: Done.

    Waiting to allow resource takeover to complete:Done.

    Starting High-Availability services: IPaddr[11351]: INFO: Resource is stopped
    Done.

  69. Je serais tenté de dire que le service que Heartbeat surveille est stoppé….ou alors que je service que tu renseigne n’est pas bon.

    Sinon ca fonctionne? tu as l’IPV? si tu stop un serveur manageur, l’autre fonctionne toujours avec l’IPV?

  70. pb précédent SOLVED :
    j’ai tout refait proprement en supprimant les trucs inutiles côté manager ou data node
    et tout fonctionne bien. en bref :
    Il faut bien utiliser shutdwon depuis un des serveurs managers pour couper le cluster
    avant modif.
    On fait ces modifs dans le .ini
    On redémarre manager : sudo ndb_mgmd –skip-config-cache –reload –config-
    file=/var/lib/mysql-cluster/config.ini
    On redémarre les noeuds data : ndbd –initial (–initial si modif de config.ini
    seulement)
    Et çà marche, le nouveau de fichier est bien pris en compte. (pour ma part c’était
    DataMemory et IndexMemory)

    Juste un truc curieux pour finir : dans le fichier de config.ini quand on précise le
    dossier pour les data à mettre dans le cluster avec /var/lib/mysql-cluster par exemple :

    [NDBD]
    #IP of the second data node
    HostName=192.168.1.3
    DataDir=/var/lib/mysql-cluster

    .. je remarque que les data ne se mettent pas du tout là mais dans /usr/local/mysql-
    cluster…xxx/data/
    Les logs s’y mettent bien, mais pas les data.

    toi aussi ?

  71. Au sujet de hearbeat, plus haut dans une discussion, tu me disais :
    « Je pense qu’il ne faut pas indiquer tes fichiers de configuration dans Heartbet :
    « debian605 192.168.1.50 ndb_mgmd »
    C’est un service qui est renseigné pour voir si il tourne, Je ne pense pas que heartbeat
    soit fait pour relancer un service.
    Ducoup, si tu souhaite relancer un service down, un petit coup de script avec un
    crontab chaque seconde. »
    Donc il me reste çà dans mon fichier haresources:
    debian605 192.168.1.50/24/eth1

    sans service mentionné ..
    donc peut être que …

  72. (suite)
    si je mets çà : debian605 192.168.1.50/24/eth1 ndb_mgmd
    je ne ping plus sur l’IPV 192.168.1.50… va savoir pourquoi…

    si je mets debian605 192.168.1.50/24/eth1
    je ping bien sur l’IPV même après arrêt d’un serveur manager.

    Dans les 2 cas j’ai le même message au démarrage :

    /etc/init.d/heartbeat restart
    Stopping High-Availability services: Done.

    Waiting to allow resource takeover to complete:Done.

    Starting High-Availability services: IPaddr[15084]: INFO: Resource is stopped
    Done.

  73. En faite, l’adresse IP virtuelle n’est utilisé que du coté « application mysql ».
    Or dans le cluster, les manageurs et noeuds communique avec leurs « vrais IPs ». Ducoup, le seul service qui reçois des requêtes via l’IPV est mysql-proxy.

    MySQL Cluster étant fait de base pour fonctionner avec plusieurs manageurs en même temps, il ne sert a rien de surveillé car l’autre fonctionne toujours, le seul service a surveillé avec mysql-proxy car si il lache sur le premier, le second ne fonctionne pas en même temps comme ndb-mgmd sur le second manageur.

    Je n’avais regardé du bon point de vu, il faut donc indiqué mysql-proxy dans Heartbeat, je vais modifier le tuto.

  74. Bien joué. merci pour ta réactivité légendaire. 😉
    J’ai changé également dans haresources…
    That sounds pretty good.

    Une idée pour mon post plus haut :
    Juste un truc curieux pour finir : dans le fichier de config.ini quand on précise le
    dossier pour les data à mettre dans le cluster avec /var/lib/mysql-cluster par exemple :

    [NDBD]
    #IP of the second data node
    HostName=192.168.1.3
    DataDir=/var/lib/mysql-cluster

    .. je remarque que les data ne se mettent pas du tout là mais dans /usr/local/mysql-
    cluster…xxx/data/
    Les logs s’y mettent bien, mais pas les data.

    toi aussi ?

    merci pour tout

  75. Hello Pierre
    quand tu testes ton IPV avec tes requêtes SQL, où vas tu lire ces informations « Picked
    backend n° » que tu décris :

     »
    Plus concrètement, les termes « Picked backend n° » représentent une tentative de
    connexion à l’un des n½uds, identifié par son IP ainsi que son numéro. Le statut « done »
    nous montre que la connexion est effective, et que donc le programme peut
    fonctionner.
     »

    Merci

  76. Ok merci Pierre je vais regarder à çà c’est curieux dans le terminal non ? en live comme
    çà ? Je regarde.

    Au fait, me confirmes tu (ou non je suppose) ce que je te demandais un post plus haut :
    ——-
    Une idée pour mon post plus haut :
    Juste un truc curieux pour finir : dans le fichier de config.ini quand on précise le
    dossier pour les data à mettre dans le cluster avec /var/lib/mysql-cluster par exemple :

    [NDBD]
    #IP of the second data node
    HostName=192.168.1.3
    DataDir=/var/lib/mysql-cluster

    .. je remarque que les data ne se mettent pas du tout là mais dans /usr/local/mysql-
    cluster…xxx/data/
    Les logs s’y mettent bien, mais pas les data.

    toi aussi ?

  77. Ton /var/lib/mysql-cluster est t-il créé sur tes noeuds ? du coup si il ne l'ai pas, il écrit sans doute ailleur et donc dans /usr/local/.

    Sinon apparemment si tu a directement compilé les sources, il utilise /usr/local/mysql-cluster comme répertoire par défaut.

    « Configuration cache files. Beginning with MySQL Cluster 6.4.0, the management server by default creates configuration cache files in a directory named mysql-cluster in the MySQL installation directory. (If you build MySQL Cluster from source on a Unix system, the default location is /usr/local/mysql-cluster.) This can be overridden at run time by starting the management server with the –configdir option. »

    Pour les info du script LUA, il y a sans doute possibilité de modifier le script pour lui faire écrire dans un fichier de log.

  78. merci Pierre. oui oui mes dossiers étaient bien créés. la remarque que tu soulèves est
    intéressante sur les options par défaut.

    J’utilise –config-file sur les managers
    sudo ndb_mgmd –skip-config-cache –reload –config-file=/var/lib/mysql-
    cluster/config.ini
    Et je ne sais pas s’il faut faire qqch en particulier sur les noeuds pour indiquer un autre
    répertoire.

    Ce n’est pas très grave, mais j’aime bien quand c’est nickel et que je comprends bien
    qui fait quoi et où. 😉

    C’est pour cela que j’aimerais rapidement pouvoir utiliser cette fu… d’IPV 😉
    car je n’y suis toujours pas parvenu…

    Merci encore.

  79. La tu me parle du fichier de config de ndb_mgmd sur les manageurs mais je pense qu’il faut surtout voir sur le lancement de mysql-ndb sur les noeud et donc voir plutot les options qui sont utilisé quand celui-ci se lance.

    Deux idées comme ca, va voir dans le fichier de conf de mysql « my.cnf » sur tes noeuds et essais d’ajouter ou directement dans le fichier de conf de ndb_mysql (a trouver…)

    basedir = /var/lib/mysql-cluster
    datadir = /var/lib/mysql-cluster/data

    Pour forcer la location des fichiers, apres je ne suis pas certain du resultat…

    Faut faire la distinction sur tes noeud entre le fichier de conf de mysql (qu’on modifie pour parametrer les serveurs manageurs) et le fichier de conf de ndb_mysql (qu’on ne touche pas à la base).

    Perso je pencherais plus sur la deuxieme idées car c’est directement le processus lié à la gestion du cluster alors que MySQL est la pour se connecter au managers (je schématise grossierement…).

    Apparement tu peux jouer avec la config de ndb_mysql à l’aide de ndb_config.

    Cette page pourrait aider : http://rpm.pbone.net/index.php3/stat/45/idpl/17871482/numer/1/nazwa/ndb_config

    Faut avouer que c’est un peut le bazarre en terme de fichier de conf et location de fichier avec MySQL, et ça ne s’arange pas car cela change en fonction des versions…

  80. Hello Pierre.
    Tu penses également que l’architecture décrite et testée est OK pour un environnement
    de production ?
    Quand je vois que tu l’as réalise avec des serveurs (même si ce sont des VM) avec 256
    ou 512 de RAM, je me dis que çà va …
    Moi je testé avec des VM d’au moins 2Go de RAM, 4Go et 8Go…
    Dans mon idée, je compte prendre 2 serveurs physiques avec au moins 32Go de RAM
    chacun et d’y faire 2 VM (ou 3VM) dans chaque…
    dans chacun des 2 serveurs physiques :
    – 1 VM pour 1serveur manager (+ peut être un Serveur Web frontal + loadbalancer
    applicatif pour instances JAVA de ma 2nde VM )
    – 1VM pour mon applicatif JAVA (sur serveur d’applications Glassfish 3.1.2)
    – 1 VM pour mes Data ( dans un cluster MySQL 7.2 copiées sur la VM correspondante
    du second serveur phys.)

    Qu’en penses tu ? y vois tu un éventuel pb (ou limitation) vu comme cela ?

    faut que j’arrive à utiliser mon IPV…;-(

    Merci pour tout

  81. hello
    je viens de noter que j’ai des erreurs en lançant mysql-proxy
    je crois bien que j’y avais mis les droits sans jamais le lancer, on comprend pourquoi çà
    ne fonctionne pas très très bien…. ;-(

    toi tu as çà

    quand je lance /etc/init.d/mysqlp.sh j’ai ce genre d’erreur :

    2012-10-27 00:30:40: (critical) chassis-mainloop.c:102: chassis is build against
    libevent 1.4.13-stable, but now runs against 1.4.9-stable
    2012-10-27 00:30:40: (message) Initiating shutdown, requested from chassis.c:461
    2012-10-27 00:30:40: (message) shutting down normally, exit code is: 1
    ./mysqlp.sh: line 12: –proxy-backend-addresses=192.168.1.2:3306 : commande
    introuvable
    ./mysqlp.sh: line 13: –proxy-backend-addresses=192.168.1.3:3306 : commande
    introuvable
    ./mysqlp.sh: line 14: –admin-username=root : commande introuvable
    ./mysqlp.sh: line 15: –admin-password=mypasswd : commande introuvable
    ./mysqlp.sh: line 16: –proxy-lua-script=/etc/mysql/mysql-proxy/script.lua: Aucun
    fichier ou dossier de ce type
    ./mysqlp.sh: line 17: –admin-lua-script=/etc/mysql/mysql-proxy/script.lua: Aucun
    fichier ou dossier de ce type
    ./mysqlp.sh: line 18: –keepalive : commande introuvable
    ./mysqlp.sh: line 19: –log-level=debug : commande introuvable

    si tu as une idée..

  82. Salut,

    Je pense que c’est simplement un problème de disposition de parametres dans le script, essais de mettre les paramettres les uns à la suite des autres plutot que de sauter une ligne apres « mysql-proxy ».

    Sinon pour ta question précedente, la seul limitation que je pourrais voir c’est au niveau des interfaces réseaux qui sont pas mal solicité avec beaucoup de requêtes car tu à une base de données derière donc ne pas avoir une seul interfaces réseau sur chaque serveur…mais je pense que tu y avais déjà pensé.

  83. merci Pierre je vais regarder ce soir pour mysql-proxy
    en plus de la disposition, il me parle de çà : (critical) en plus :

    chassis-mainloop.c:102: chassis is build against
    libevent 1.4.13-stable, but now runs against 1.4.9-stable

    Pour les serveurs en prod, je te disais que je me posais la question de mettre en place
    la même architecture qu’en dev c’est à dire avec des VMs (donc on met des cartes
    réseau un peu comme on veut)
    Penses tu que çà ralentisse beaucoup les requêtes vers BDD ou autres des VM plutôt
    que des sevreurs réels (pour le trading algo et la nanoseconde, certainement mais
    sinon ?)

    merci encore

  84. je me suis réinstallé les dapendances nécessaires pour mysql-proxy, j’en ai profit » pour
    en mettre des stables plu récentes et maintenant j’ai çà comme message d’erreur mais et
    je ne trouve pas de solution… çà devient pénible qd même … 😉

    mysql-proxy: symbol lookup error: mysql-proxy: undefined symbol:
    chassis_frontend_init_glib

  85. Salut,

    Problème avec glib que tu a du installé avec mysql-proxy, donc a voir si y a pas une mise à jour ou autre…

    Au moment de faire ce projet, la version de mysql-proxy qui était disponible en « install facile » ne gérais rien, c’est pour ça que c’est une partie compliqué du tuto.

    Il faudrait éventuellement voir si il n’y a pas une nouvelle mise à jour de mysql-proxy qui rendrait l’installation moins chiante.

  86. Hello
    Je te tiens logiquement informé puisque tu m’as toujours été d’une grande utilité.
    J’ai réussi à faire fonctionner tout çà. Je suis reparti des fichiers sources (pour Debian)
    de mysql-proxy 0.8.0. Tu as raison, pense qu’aujourd’hui un bon vieux apt-get install
    devrait le faire. 😉
    Et j’ai réussi à plugger mon cluster sur Glassfish, via l’IPV
    fallait rentrer une URL du style :
    jdbc:mysql:loadbalance://IPV:4040/schema
    Je me rends compte que le serveur d’application Java gère peut être cela sans passer
    par mysql-proxy avec ses propres algo de loadbalancing…Robin etc ..
    l’URL serait alors
    jdbc:mysql:loadbalance://datanodehost1:3306,datanodehost2:3306/schema
    Cela peut pourra en aider certains je pense.

    Juste une question sur mysql cluster : quelle différence tu fais entre « nb de réplicas » et  »
    nb de noeuds » ? — je ne sais pas encore bien ce point pourtant il y a une vraie
    différence apparemment, ce sont 2 param différents

    MERCI à toi.

  87. Salut,

    NoOfReplicas correspond aux nombre de noeuds qui stock des données et donc qui se repliquent entre eux et donc qui sont des noeuds de stockage.

    NoOfNodes correspond au nombre de noeuds qui ne stock pas de données mais qui exéxute uniquement des requetes MySQL.

    Ici, les quatres noeuds stockent des données et se repliquent entre eux donc il y a NoOfReplicas = 4.

    Par exemple, on aurait pu avoir uniquement 2 noeud de stockage et 2 noeud simple soient : NoOfReplicas = 2 / NoOfNodes = 0

  88. Hello j’espère que tu vas bien.

    j’avais loupé ta réponse ;-(
    je te remercie, c’est clair.
    Et justement, comme mes serveurs sont complètement virtualisés, je vais séparer,les
    managers(ndb_mgm), des noeuds data(ndbd), des noeuds qui executent les requetes
    (mysqld) dans des VM différentes.

    Mais je ne vois pas comment communiquent les noeuds data des noeuds executant les
    requetes s’ils sont sur des serveurs séparés… où précise t on qu’il faut aller chercher
    les data dans un dossiers distant ?

    Merci encore
    Bien à toi

  89. Salut,

    Donc effectivement dans mon exemple les noeuds données et exécutant les requêtes sont les mêmes.

    La suite, je ne l'ai pas testé, mais se sont de fortes suppositions.

    Tout est mis dans la configuration des serveurs managers dans :

    /etc/mysql/ndb_mgmd.cnf

    Le nombre de noeuds de données est défini par le nombre de fois où est inscrit [NDBD]

    La location des données est défini par :

    DataDir=/var/lib/mysql-cluster

    Et donc dans la console de management « ndb_mgm », les noeuds data seront dans [mysqld(API)].

    Tu devrais donc avoir 2 serveurs dans [mysqld] et [mysqld(API)]

    Voici une configuration qui pourrait faire l'affaire :

    [ndbd] # Serveur Data 1
    HostName = 192.168.0.1
    DataDir=/var/lib/mysql-cluster

    [ndbd] # Serveur Data 2
    HostName = 192.168.0.2
    DataDir=/var/lib/mysql-cluster

    [mysqld] # Serveur MySQL 1
    HostName = 192.168.0.3

    [mysqld] # Serveur MySQL 2
    HostName = 192.168.0.4

    Il faut aussi penser à supprimer les lignes des serveurs qui ne sont pas des serveurs exécutant les requêtes dans la configuration de mysql_proxy :

    –proxy-backend-addresses=XXX.XXX.XXX.XXX:3306

  90. bah oui merci bien vu !
    je vais regarder tout çà et te tiens au jus.
    en séparant comme çà on conserve uniquement un my.cnf
    sur les serveurs mysql ?
    rien d’autre que les data sur les data nodes ou ..

    merci encore

  91. le truc un peu chelou est que j’ai çà (dans les services démarrés) qd je démarre le mysql server :

    mysql 6748 1.0 1.0 398704 42260 pts/0 Sl 16:04 0:00 /mysqld/mysql/bin/mysqld –basedir=/mysqld/mysql –datadir=/mysqld/mysql/data –plugin-dir=/mysqld/mysql/lib/plugin –user=mysql –log-error=/

    donc il ne va pas chercher les data du noeud data..

    et pourtant le manager me sort les bonnes infos :

    ndb_mgm> show
    Connected to Management Server at: localhost:1186
    Cluster Configuration
    ———————
    [ndbd(NDB)] 1 node(s)
    id=2 @192.168.0.30 (mysql-5.5.28 ndb-7.2.9, Nodegroup: 0, Master)

    [ndb_mgmd(MGM)] 1 node(s)
    id=1 @192.168.0.26 (mysql-5.5.28 ndb-7.2.9)

    [mysqld(API)] 1 node(s)
    id=3 @192.168.0.28 (mysql-5.5.28 ndb-7.2.9)

    curieux

  92. Je vais à nouveau partir dans des suppositions car je ne peux pas tester.

    Je pense que les serveurs mysql prennent toute les décisions avec les info renseignées dans son fichier de conf.
    En effet, tu remarquera que la seul configuration faite sur les serveurs mysql est l'indication des serveurs manager et rien d'autre.

    Dans mon tuto, il va chercher les données sur le serveur mysql même, puisqu'on lui indique le repertoire « /var/lib/mysql-cluster » via le fichier de conf des manageurs.

    Donc logiquement, si on modifie le fichier de conf des serveurs manageurs en lui indiquant d'autres serveur de stockage, il va aller stocker ailleur.

    Egalement, je te rappel qu'on indique les tables concernées par le Cluster MySQL à l'aide de « ENGINE=NDBCLUSTER ».

    Ainsi, ligne de processus que tu me montre est simplement le lancement par default du processus mysqld avec comme paramettre « –datadir », qui est le repertoire local ou sont « normalement » stocké les données par default et donc non concerné par le « ENGINE=NDBCLUSTER ».

    Ayant testé la chose je peux te confirmer que les tables ou ne sont pas indiquées « ENGINE=NDBCLUSTER » sont stockées localement et ne sont pas répliqué grace à MySQL Cluster.
    Si tu le souhaitais tu pourrais directement faire des requêtes sur un serveur MySQL et celui-ci irrait chercher dans sa base local.

    Ce qui ammene a ma conclusion, qu'a partir du moment ou il est utilisé « ENGINE=NDBCLUSTER », la conf des seveurs manageur est prioritaire sur la conf local et donc sur les paramettres du processus que tu me montre.

  93. merci pour ta réponse
    tout ce que tu me dis, je le pensais (pense) aussi. si je n’utilise pas NDBCLUSTER
    çà stocke en local, pas dans le cluster. normal
    Le fait est que j’ai toujours utilisé NDBCLUSTER est que çà fait gonfler l’espace utilisé de
    mes serveur mysqld alors que que je n’ai pas prévu qu’ils soient gros
    je crois que sur les serveurs mysql sont conservés la structure des tables, cad les
    fichiers .myd et .frm mais pas les data : .MYI

    Et quand bien même je supprime tout, coupe tous les noeuds et supprime les fichiers
    créés : les fameux ibdata1 (sur serveurs SQL et sur noeuds), au lancement ds serveurs
    mysql à nouveau ces fichiers sont regénérés… (c’est ptet la force du cluster mais là
    pour le coup, j’en veux plus.. 😉 )
    Je ne pense pas que ce soit normal d’avoir ces fichiers à cet endroit…

    Pas de différence à utiliser mysqld ou mysql.server normalement ?

  94. Bonjour,

    Merci pour ce tuto qui est toujours utile 🙂

    Une petite question ? peut-on ajouter des nodes SLAVE ?

    Car si j’ai bien compris, ce système permet, en cas de saturation du MASTER de switcher sur une node SLAVE,
    mais est il possible d’ajouter une troisième (voir plus) node SLAVE en cas de saturation de la node SLAVE
    précédente ?
    Dans ce cas, on aurait un système plutôt pratique qui allouerait plus de serveur en cas de pic d’audience.

    Je vais tenter de mettre ce système en place dans une baie virtuelle regroupant plusieurs serveurs (de ce fait,
    je dispose d’une communication en local de 100 Gbps)

    Merci de votre réponse.
    Cordialement

  95. Bonjour Romain,

    Comme explique dans le tuto, il est possible de monter jusqu’à 64 serveurs managers et 256 serveurs nodes.

    Le Master switch sur le slave quand il est HS et non en cas de saturation, ceux-ci sont actif / passif et non actif / actif, il
    est donc possible d’ajouter 63 slaves. Je ne pense pas que les serveurs manageurs puissent arriver a saturation car
    aucun calcul n’est fais dessus, ceux-ci redirige simplement les requêtes sur les 4 serveur nodes, donc si tu souhaite
    augmenter la capacité de traitement il faut donc augmenter le nombre de serveur nodes (c’est assez simple)

    Il est possible que certain point de la configuration est changé car le tuto date un peu et mysql a évolué entre temps.

  96. Bonjour,

    merci pour votre réponse, j’ai rencontrer plusieurs problème après ma tentative d’installation sur des serveurs
    faisant parti d’une baie virtuelle.

    est il possible de rentrer en contact par email/skype pour une aide approfondi ?

    Cordialement

  97. Bonjour Pierre,

    j’ai reussi la mise en place de mon cluster mysql cependant je n’utilise pas la même architecture :

    j’ai une management node, 2 data node et 2 mysql node.

    J’ai réussi à mettre en place ma base de donnée qui est correctement répliquée.

    Cependant je me suis connecter directement à une mysql node pour effectuer mes requêtes de test, n’est il
    pas possible de se connecter à la node management (en php par exemple) pour se connecter à la base de
    donnée ?

    Si oui je ne sais pas comment faire, si non, cela revient a dire que la node management ne sert uniquement à
    la configuration du cluster et peut donc (peut être) être greffé à une mysql node ou une data node ?

    Merci de ton aide.

  98. Bonjour Pierre,

    Une question :

    Dans le fichier lua pour mysql-proxy, je ne passe jamais dans la fonction pick_random() lors de mes tests de
    connexions et de requetes, du coup, je ne sais pas vraiment si mon load balancing fonctionne.

    Aurais tu une explication ?

    Merci de ta réponse.
    Cordialement

  99. Bonjour,

    J’ai suivi votre tuto, un peu mélangé à d’autres pour l’adapter à mes besoins.
    Il y a une info que je ne trouve nulpart, sur aucun site, aucun tuto :

    Une fois que le cluster est monté et fonctionnel d’après les tests indiqués : comment ca marche
    ??

    Je veux dire, un client SQL envoi une requête à quelle IP, la VIP gérée par le Heartbeat ?
    Donc en gros, c’est un noeud de Management qui reçoit la requête, et va la distribuer à un noeud
    SQL en fonction du LUA définit dans MySql Proxy ?
    Pour ma part, ce « schéma » ne marche pas chez moi. J’ai l’impression que comme il n’y a pas de
    « moteur » mysql sur les management, je n’arrive tout simplement pas à m’y connecter.

    Par contre, si je lance une requête sur n’importe quel noeud SQL, la ca marche, je peux faire un
    select d’une base, etc… Mais ce n’est pas le but d’attaquer directement les serveurs SQL.

  100. J’ai tapé un peu vite, je viens de voir les posts de « Romain » juste au dessus :p
    Mais juste « Problème réglé » ne me suffit pas, si l’un ou l’autre avez des explications plus
    concrètes..

    Cdt,

  101. Bonjour Jerome,

    Il faut attaquer uniquement la VIP, c’est le but du cluster, d’avoir une seul entrée (la VIP) que tu spécifies dans tes
    applications et donc qui ne change jamais, et derrière tu peux mettre autant de serveurs que tu veux pour gérer
    la mise en charge.

    Effectivement il est possible d’attaquer un serveur noeud directement car ceux-ci restent des serveurs mysql,
    mais tu perd l’internet du cluster qui est de repartir la charge sur ses serveurs grave au script LUA avec mysql-
    proxy.

    Il n’y a pas de donnée stocké sur les serveurs manageurs, ceux-ci sont présent uniquement pour rediriger les
    requêtes vers les noeud.

    Ci cela ne fonctionne pas en connexion depuis la VIP alors que la connexion direct sur les noeuds fonctionne,
    c’est donc que le problème est sur les serveurs manageurs, que donne la commande « ndb_mgm » ?

  102. Bonjour,

    Merci pour la réponse rapide !
    Voici un résultat du « show » de ndb_mgm :

    root@NVSQLmgr01:~# 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 @172.16.4.3 (mysql-5.6.21 ndb-7.3.7, Nodegroup: 0, *)
    id=4 @172.16.4.4 (mysql-5.6.21 ndb-7.3.7, Nodegroup: 0)

    [ndb_mgmd(MGM)] 2 node(s)
    id=1 @172.16.4.1 (mysql-5.6.21 ndb-7.3.7)
    id=2 @172.16.4.2 (mysql-5.6.21 ndb-7.3.7)

    [mysqld(API)] 2 node(s)
    id=5 @172.16.4.5 (mysql-5.6.21 ndb-7.3.7)
    id=6 @172.16.4.6 (mysql-5.6.21 ndb-7.3.7)

    ndb_mgm>

    Les 2 managers, les 2 SQL et les 2 stockages sont bien présents.

    Au niveau du Mysql Proxy, j’ai bien mis l’adresse VIP dans Proxy-address, comme ceci : proxy-
    address = 172.16.4.10:3307
    Par contre, je ne sais pas attaquer un Mysql distant avec un port spécifique.
    je connais la commande mysql -h 172.16.4.10 -u mysql -p
    Mais comment indiquer un port autre que le 3306 ?
    Lorsque je fais cette commande, j’obtiens ceci :
    ERROR 2003 (HY000): Can’t connect to MySQL server on ‘172.16.4.10’ (111)

    A première vue, ce n’est pas un problème d’accès, car j’ai bien appliqué les GRANT sur la bdd, et
    le message d’un problème d’accès est différent et bien défini. Par exemple depuis un server qui
    n’a rien a voir avec le cluster :
    ERROR 1130 (HY000): Host ‘172.16.0.30’ is not allowed to connect to this MySQL server

    Au passage, j’ai repéré des erreurs dans mon script.LUA.
    Le copier collé du site vers mon éditeur texte a rajouté des « ? » un peu partout, j’ai du refaire
    du ménage.

    Vois-tu des points à vérifier ?

    Cdt,

    Jérôme

  103. La premiere chose qui me saute aux yeux est que les serveurs mysql ([mysqld(API)]) et noeuds ([ndbd(NDB)]) sont
    différents, c’est normal?

    Pour attaquer un serveurs sur le port autre que 3306, apparement c’est le paramètre –port=PORT

  104. oui c’est normal. J’ai 6 machines : 2 managers, 2 « moteur sql », et 2 stockages

    Ajouter un port fonctionne, et a mis le doigt sur une autre erreur, dans le script LUA celle ci :
    mysql -h 172.16.4.10 –port=3307 -u mysql -p
    Enter password:
    ERROR 1105 (HY000): #07000MySQL Proxy Lua script failed to load. Check the error log.

    -> ca sous entend que la connexion va bien taper sur la VIP, et du coup sur le MySql Proxy.

    J’ai rendu le script exécutable (744 au lieu de 644) et je l’ai lancé manuellement, j’obtiens le
    résultat suivant :

    root@NVSQLmgr01:~# /etc/mysql/mysql-proxy/script.lua
    /etc/mysql/mysql-proxy/script.lua: ligne 1: Erreur de syntaxe près du symbole inattendu «
    os.time »
    /etc/mysql/mysql-proxy/script.lua: ligne 1: `Math.randomseed(os.time())’

    Je vais tester avec un autre script pour voir, si c’est bien ce point qui pose problème. Je vais
    bien trouver ça sur Google.

  105. Juste pour info, voici l’erreur qui se trouve dans les logs :

    2015-01-26 15:41:09: (critical) network-mysqld-lua.c:234: lua_load_file(/etc/mysql/mysql-
    proxy/script.lua) failed: [string « /etc/mysql/mysql-proxy/script.lua »]:4: ‘=’ expected near
    ‘pick_random’
    2015-01-26 15:41:09: (debug) last message repeated 1 times
    2015-01-26 15:41:09: (debug) abs wait-for-event::done usec= 0
    2015-01-26 15:41:09: (debug) abs lua-exec::done usec= 0

  106. Je pense aussi ^^ Par contre c’est juste un copier coller du tuto..
    Pour info, j’ai testé avec d’autres scripts (présents dans /usr/share/mysql-proxy), et j’ai testé
    sans aucun script, j’obtiens la même erreur : ERROR 1043 (08S01): Bad handshake
    Je suis entrain de fouiller avec Google, mais pour l’instant ce n’est pas mon ami.

    Cdt,

    Jérôme

  107. Apparement ca serait un problème de version de mysql ou mysql-proxy,
    (https://bugs.launchpad.net/maria/+bug/982664)

    Le tuto datant un peu, concernant mysql je pense que tu as la dernière version, par contre pour mysql-proxy, le
    liens de téléchargement que je propose date beaucoup et donc le problème doit venir du fait que la dernière
    version de mysql doit mal communiquer avec la vieille version de mysql-proxy.

    Va voir par ici pour la dernière version de mysql-proxy : http://dev.mysql.com/downloads/mysql-proxy/

  108. Bonjour,

    J’ai vu ça, le problème de concordance de version.
    C’est plutôt étrange dans ce cas la car en théorie, j’ai des choses assez récentes.
    J’ai aussi fait un apt-get update et upgrade, mais sans succès.
    Niveau MySQL, j’ai ceci :
    mysql Ver 14.14 Distrib 5.6.21-ndb-7.3.7, for linux-glibc2.5 (x86_64) using EditLine wrapper
    (Le package vient du site officiel MySql, avec le fichier mysql-cluster-gpl-7.3.7-linux-glibc2.5-
    x86_64.tar.gz téléchargé sur http://dev.mysql.com/downloads/cluster/ )

    Niveau Proxy MySql, j’ai cette version (obtenue avec un apt-get install mysql-proxy):
    mysql-proxy 0.8.1
    chassis: mysql-proxy 0.8.1
    glib2: 2.30.1
    libevent: 2.0.21-stable
    LUA: Lua 5.1.4
    package.path: /usr/lib/mysql-proxy/lua/?.lua
    package.cpath: /usr/lib/mysql-proxy/lua/?.so
    — modules
    admin: 0.8.1
    proxy: 0.8.1

    Il y a la 0.8.5 de disponible, mais en alpha. Je n’ai pas pris le risque.
    Je vais le tenter quand même, au cas ou.

  109. mysql-proxy étant visiblement très peu mis à jour, apparement chacune d’entre elles apporte quand meme pas
    mal de nouveauté, je ne serais serais pas étonné que la 0.8.4 corrige ton problème.

  110. Je suis entrain d’essayer ça. Mais MySQL-Proxy n’est pas simple à installer, il y a 3 tonnes de
    dépendances ! (plus que tu n’en as eu visiblement)
    Je te ferai un retour lorsque j’aurai terminé, pour l’instant je m’arrache tranquillement les
    cheveux dans mon coin :p

    Cdt,

    Jérôme

  111. Je ne voulais pas polluer les commentaires, et j’ai essayé la page « contact », mais l’envoi du
    message me renvoi « Erreur interne ». du coup, je pollue ici :

    Pour l’instant c’est un peu la misère, j’ai du mal à installer MySQL-Proxy.
    En fait, quand j’ai dit que le 85 était une alpha, toutes les versions sont considérées comme des
    alphas (http://downloads.mysql.com/archives/proxy/)

    Comme paquet de Cluster Management, j’utilise celui ci : mysql-cluster-gpl-7.3.7-linux-glibc2.5-
    x86_64.tar.gz
    C’est le dernier dispo. (il y a une version RC plus évoluée, mais je n’ai pas pris).

    J’ai plusieurs problèmes différents, selon les méthodes utilisées :

    1 – Soit j’installe les dépendances le plus difficilement possible :

    apt-get install pkg-config
    apt-get install automake
    apt-get install autoconf
    apt-get install flex
    apt-get install libtool
    apt-get install liblua5.1-0-dev
    apt-get install liblua50-dev
    apt-get install liblualib50-dev
    apt-get install lua5.2
    apt-get install libmysqlclient15-dev

    mkdir /usr/src/libevent
    cd /usr/src/libevent
    wget http://downloads.sourceforge.net/project/levent/libevent/libevent-2.0/libevent-2.0.22-
    stable.tar.gz
    tar zvfx libevent-2.0.22-stable.tar.gz
    cd libevent-2.0.22-stable
    ./configure
    make
    make install

    ### DEBUT Install des dépendances de GLIB.

    mkdir /usr/src/zlib
    cd /usr/src/zlib
    wget http://zlib.net/zlib-1.2.8.tar.gz
    tar zvfx zlib-1.2.8.tar.gz
    cd zlib-1.2.8
    ./configure
    make
    make install

    mkdir /usr/src/libffi
    cd /usr/src/libffi
    wget ftp://sourceware.org/pub/libffi/libffi-3.2.1.tar.gz
    tar zvfx libffi-3.2.1.tar.gz
    cd libffi-3.2.1
    ./configure
    make
    make install

    apt-get install gettext

    ### FIN Install des dépendances de GLIB.

    mkdir /usr/src/glib
    cd /usr/src/glib
    wget http://ftp.gnome.org/pub/gnome/sources/glib/2.43/glib-2.43.3.tar.xz
    tar xpvf glib-2.43.3.tar.xz
    cd glib-2.43.3
    ./configure
    make
    make install

    ####Ici j’évite GTK-doc qui prend 1Go de téléchargement et qui si j’ai bien compris ne nous
    servira pas à grand chose.

    Puis j’installe MySQL-Proxy
    récupérer les sources Linux : http://dev.mysql.com/downloads/mysql-proxy/
    mysql-proxy-0.8.5.tar.gz
    cd /usr/src/mysql-proxy (créer si besoin)
    tar zxf mysql-proxy-0.8.5.tar.gz
    cd mysql-proxy-0.8.5
    ./configure
    make
    make check
    make install

    Et la, le Make Check est pas content du tout. J’ai doit à un message sur Glib type GLib version
    too old (micro mismatch).

    2 – Du coup, j’ai refait une tentative d’install, mais avec glib installé en apt-get (apt-get
    install glib2.0), sans zlib ni libffi, puisqu’installé automatiquement via glib.
    Ca donne :
    apt-get install pkg-config
    apt-get install automake
    apt-get install autoconf
    apt-get install flex
    apt-get install libtool
    apt-get install liblua5.1-0-dev
    apt-get install liblua50-dev
    apt-get install liblualib50-dev
    apt-get install lua5.2
    apt-get install libmysqlclient15-dev

    mkdir /usr/src/libevent
    cd /usr/src/libevent
    wget http://downloads.sourceforge.net/project/levent/libevent/libevent-2.0/libevent-2.0.22-
    stable.tar.gz
    tar zvfx libevent-2.0.22-stable.tar.gz
    cd libevent-2.0.22-stable
    ./configure
    make
    make install

    apt-get install glib2.0

    Mais la j’ai l’erreur suivante pendant le Check :
    sh: 1: mysqltest: not found
    ./lua-runner: ./run-tests.lua:543: unexpected result <>FAIL: base
    ========================================================
    1 of 1 test failed
    Please report to mysql-proxy-discuss@lists.launchpad.net
    ========================================================
    Makefile:488: recipe for target ‘check-TESTS’ failed
    make[4]: *** [check-TESTS] Error 1
    make[4]: Leaving directory ‘/usr/src/mysql-proxy/mysql-proxy-0.8.5/tests/suite’
    Makefile:617: recipe for target ‘check-am’ failed
    make[3]: *** [check-am] Error 2
    make[3]: Leaving directory ‘/usr/src/mysql-proxy/mysql-proxy-0.8.5/tests/suite’
    Makefile:364: recipe for target ‘check-recursive’ failed
    make[2]: *** [check-recursive] Error 1
    make[2]: Leaving directory ‘/usr/src/mysql-proxy/mysql-proxy-0.8.5/tests/suite’
    Makefile:347: recipe for target ‘check-recursive’ failed
    make[1]: *** [check-recursive] Error 1
    make[1]: Leaving directory ‘/usr/src/mysql-proxy/mysql-proxy-0.8.5/tests’
    Makefile:342: recipe for target ‘check-recursive’ failed
    make: *** [check-recursive] Error 1
    root@NVSQLmgr01:/usr/src/mysql-proxy/mysql-proxy-0.8.5#

    3 – Et lorsque j’installe Mysql-proxy en apt-get, tout va bien, mais c’est la version 0.8.1 qui
    tombe et je me retrouve avec le soucis de ERROR 1043 (08S01): Bad handshake

    Autre point parallèle, lorsque j’installe en apt-get, je peux faire « service mysql-proxy
    start/stop/restart »
    Pas quand je l’installe en ./configure, make, make install. Ca c’est pas très pratique, mais bon,
    pas trop vital non plus.

    Du coup j’ai envisagé de downgrader ma version de mysql-cluster, jusqu’à en trouver une
    compatible avec mysql-proxy 0.8.1, mais c’est un peu dommage.

    Donc pour l’instant, je suis un peu au point mort. Je continue mes recherches, et je te tiendrai
    informé quand j’aurai trouvé.

    Cdt,

    Jérôme

  112. Bonjour,

    bon, après quelques nouvelles tentatives, une 100ene d’écrasements de mes VHD pour recommencer
    (je travaille sur des VM HyperV), des re-re-re-re-re-re téléchargements de paquets…
    Ca marche !
    J’arrive à faire tourner le cluster avec Mysql-Proxy. C’était effectivement bien un problème de
    version entre Mysql-Cluster et Mysql-Proxy.
    En faisant un apt-get install mysql-proxy (sur du Ubuntu), on récupère la 0.8.1 (c’est tout ce
    qu’il y a dans les dépots).
    Et la, j’ai downgrader ma version de Mysql-Cluster à la 7.2.19, téléchargeable sur le site
    officiel : mysql-cluster-gpl-7.2.19-linux2.6-x86_64.tar.gz

    Je n’ai pas encore fini mon tuto.
    Il me reste à régler le problème du script LUA qui ne marche pas (pour l’instant, je lance Mysql-
    Proxy sans rien)
    Il faut également que j’indique comment créer une base « compatible ».
    Et je veux aussi rajouter un laïus sur comment paramétrer correctement le volume de DataMemory et
    d’IndexMemory déclarer dans le config.ini, en fonction des capacités machines, etc…

    Mais mis à part ce « détail », la partie mécanique est déjà fonctionnelle. Tu veux un exemplaire ?
    C’est relativement long, en commentaire ca sera peut-être moyen. Je vais essayer la page Contact
    de nouveau.

    Cdt,

    Jérôme

  113. Bonjour,

    J’ai encore quelques soucis de fonctionnement, même si le « squelette » est opérationnel.
    Je n’arrive pas à faire tourner ton script LUA de Roud-Robin. Du coup j’ai opté pour le Rw-
    splitting proposé dans le package Mysql-Cluster.

    Je suis entrain de faire des tests de perf pour affiner les réglages de DataMemory et
    d’IndexMemory, et au passage m’assurer que le splitting marche bien.

    Un peu de patiente encore et je te donnerai mes recherches. Je préfère copier un truc juste
    plutôt qu’inachevé et plein d’erreurs.

    Cdt,

    Jérôme

  114. Bonjour,

    Un petit mot pour dire que j’avance dans mes recherches.
    J’ai corrigé le script LUA de ton tuto pour qu’il soit fonctionnel. Les majuscules des
    différentes commandes posaient problème (If au lieu de if, Then au lien de then, etc…) et aussi
    des  » qui manquaient, etc.. voici le script corrigé :

    math.randomseed(os.time())
    Debug_output = true

    function pick_random()
    local randomstart = math.random(1, #proxy.global.backends)
    local count = 1
    local a = {}
    for I = randomstart, #proxy.global.backends do
    A[count] = i
    count = count + 1
    end
    if randomstart > 1 then
    for I = 1, randomstart-1 do
    A[count]=i
    count = count + 1
    end
    end
    for I = 1, #proxy.global.backends do
    local myIndex = a[i]
    local s = proxy.global.backends[myIndex]
    if s.state ~= proxy.BACKEND_STATE_DOWN then
    Proxy.connection.backend_ndx = myIndex
    if debug_output == true then
    print (« Picked backend  » ..myIndex..  » –  » ..s.dst.name)
    end
    return true
    else
    print (« UNDESIRED: backend » ..myIndex..  » –  » ..s.dst.name.. « is DOWN »)
    end
    end
    return false
    end

    J’aimerais savoir maintenant comment tu fais pour vérifier si le roud robin fonctionne. Car la,
    quand je bombarde ma VIP, c’est toujours la même machine qui prend.

    Ce qui est étrange également, c’est que mes 2 serveurs de stockage tournent à plein régime, et je
    n’ai qu’un seul serveur SQL qui tourne. Comme si leurs rôles étaient inversés.

  115. Bonjour,

    n’étant pas du tout doué en Web, je me demandais si il était possible de votre part de partager le code web permettant de réaliser cette interface ?

    Très bon article au passage.

    Merci,

    Original.

  116. Bonjour Pierre,

    Je réalise un projet de fin d’étude  » Mise en place d’un cluster base de données multi-instance sur deux sites géographiquement éloignés.  »

    La Problématique :
    Avoir une haute disponibilité des ressources publiées entre 2 sites. une disponibilité et stabilité des ressources proche de 100 %. Tolérance zéro pour les pannes
    matérielles ou logicielles. Répartition des charges entre les n 1/2 uds du cluster.

    1) La mise en place entre 2 sites : Un site sur une ville et un Site sur une autre ville.

    2) Liaison sera physique : lien point à point , on a opté pour l’utilisation du système DWDM (Dense Wavelength Division Multiplexing), et le Module de transcepteur SFP à fibre optique monomode. ( En fonction de vitesse et de distance… )

    3) Caractéristiques de la Base de données :
    La Taille : 2Tera.
    Temps de réplication : asynchrone / 1 heure entre 2 sites.
    Utilisation de 4 liens.

    BD : Estimation pour 200.000 Utilisateurs. ( le cas actuel 5000 utilisateurs par Site ).

    4) La BD sera pour un nouveau service qui est en cours de la mise en place
    d’un service StaaS (STorage as a Service) à des fins de sauvegarde et de partage de fichiers.

    La légitimité sera juste pour les utilisateurs VIP ( les 5000 utilisateurs actuels )
    Après il y aura une généralisation pour les 200.000 utilisateurs.

    5) Tolérance aux pannes :Si par exemple le site rabat tombe en panne, le site Casa prend intégralement le relais.

    6) Accès : La BD sera accessibles par les 2 sites. l’utilisateur ou le client va accéder par Internet ( depuis un mobile ou un device ) Si par exemple un utilisateur est connecté depuis Ville1 avec l’aide des solutions GSLB (Global Server Load Balancing) et SLB (Server Load Balancing) qui font la résolution des noms et qui en fonction du moniteur de serveur peuvent orienter vers un service particulier. Cet utilisateur solicite son DNS et son DNS solicite le GSLB ou SLB afin de l’orienter soit sur le site Ville1 ou Ville2.

    Si par exemple un Client X se connecte sur Ville1, il sera toujours connecté sur Ville1. Nom de domaine résolu à Adresse IP sur Rabat ( Il y aura pas d’accès concurrent au niveau de la base sur les 2 sites. )

    7) Sécurité :
    – Utilisation de plusieurs Firewall applicatif.
    – IPS, Intrusion Prevention System.
    – Gestion des événements et des informations de sécurité (SIEM).

    N.B >> Le choix de MySQL était acté parce que l’application derrière fonctionne avec MySQL. ( Par rapport au STaaS).

    Ma Question concerne l’Architecture :
    J’aurais besoin d’une proposition d’architecture simple à mettre en place. Je vous serais très reconnaissant si vous pouviez me proposer une architecture simple et rapide à mettre en place ainsi que les modifications à prendre en considération concernant l’installation, la configuration… ETC

    Merci Infiniment.

  117. Bonjour Pierre,

    Je réalise un projet de fin d’étude  » Mise en place d’un cluster base de données multi-instance sur deux sites géographiquement éloignés.  »

    La Problématique :
    Avoir une haute disponibilité des ressources publiées entre 2 sites. une disponibilité et stabilité des ressources proche de 100 %. Tolérance zéro pour les pannes
    matérielles ou logicielles. Répartition des charges entre les n 1/2 uds du cluster.

    1) La mise en place entre 2 sites : Un site sur une Ville1 et un Site sur Ville2.

    2) Liaison sera physique : lien point à point , on a opté pour l’utilisation du système DWDM (Dense Wavelength Division Multiplexing), et le Module de transcepteur SFP à fibre optique monomode. ( En fonction de vitesse et de distance… )

    3) Caractéristiques de la Base de données :
    La Taille : 2Tera.
    Temps de réplication : asynchrone / 1 heure entre 2 sites.
    Utilisation de 4 liens.

    BD : Estimation pour 200.000 Utilisateurs. ( le cas actuel 5000 utilisateurs par Site ).

    4) La BD sera pour un nouveau service qui est en cours de la mise en place
    d’un service StaaS (STorage as a Service) à des fins de sauvegarde et de partage de fichiers.

    La légitimité sera juste pour les utilisateurs VIP ( les 5000 utilisateurs actuels )
    Après il y aura une généralisation pour les 200.000 utilisateurs.

    5) Tolérance aux pannes :Si par exemple le site Ville1 tombe en panne, le site Ville2 prend intégralement le relais.

    6) Accès : La BD sera accessibles par les 2 sites. l’utilisateur ou le client va accéder par Internet ( depuis un mobile ou un device ) Si par exemple un utilisateur est connecté depuis Ville1 avec l’aide des solutions GSLB (Global Server Load Balancing) et SLB (Server Load Balancing) qui font la résolution des noms et qui en fonction du moniteur de serveur peuvent orienter vers un service particulier. Cet utilisateur solicite son DNS et son DNS solicite le GSLB ou SLB afin de l’orienter soit sur le site Ville1 ou Ville2.

    Si par exemple un Client X se connecte sur Ville1, il sera toujours connecté sur Ville1. Nom de domaine résolu à Adresse IP sur Rabat ( Il y aura pas d’accès concurrent au niveau de la base sur les 2 sites. )

    7) Sécurité :
    – Utilisation de plusieurs Firewall applicatif.
    – IPS, Intrusion Prevention System.
    – Gestion des événements et des informations de sécurité (SIEM).

    N.B >> Le choix de MySQL était acté parce que l’application derrière fonctionne avec MySQL. ( Par rapport au STaaS).

    Ma Question concerne l’Architecture :
    J’aurais besoin d’une proposition d’architecture simple à mettre en place. Je vous serais très reconnaissant si vous pouviez me proposer une architecture simple et rapide à mettre en place ainsi que les modifications à prendre en considération concernant l’installation, la configuration… ETC

    Merci Infiniment.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *