dbnewz

Le but de ce billet est d’installer rapidement une configuration permettant de tester le cluster MySQL.
Il existe plusieurs façons de faire, en voici une basée sur les binaires de la dernière version à ce jour, la cluster 6.2.15. Rappelez-vous que depuis la version 5.1.25 de MySQL, les binaires du cluster ne sont plus inclus mais disposent de leur propre branche.

Haute disponibilité (redondance), montée en charge et haute performance (données en mémoire vive), une architecture en “shared-nothing” (aucun élément du cluster ne partage le même hardware) et un serveur mysql doté d’un nouveau moteur de stockage (NDB encore appelé NDBCLUSTER), voici quelques caractéristiques du cluster MySQL. Voyons comment l’installer en un minimum d’étapes.

Vue d’ensemble des éléments composant un cluster

Ce schéma issu de la documentation MySQL expose les différents élements qui composent un cluster MySQL, passons-les rapidement en revue.

(more…)

Des erreurs en enchaînant des réplications? J’ai retrouvé souvent la même erreur sur des configurations en “multi master” ou celles qui utilisent des “relay slave”. Imaginons que vous ayez 3 serveurs A -> B -> C. A étant le master, B le relay slave et C le slave. Tout se passe bien, le résultat de la commande “show slave status” vous informe que tout roule et pourtant le slave (C) n’est pas à jour. Alors pourquoi? magie vaudou?
Non! Vous avez tout simplement oublié d’ajouter sur votre relay slave (B) le paramètre “log-slave-updates”.

Un slave n’enregistre pas dans son journal (ses binlogs) les commandes qu’il reçoit de son master. Donc dans notre cas (B) est à jour mais (C) n’a aucun moyen de connaître les commandes car (C) lit juste les binlogs de (B).

En rajoutant log-slave-updates dans le my.cnf de (B), il écrira toutes les commandes dans les binlogs et (C) sera ainsi à jour.

C’est aussi un bon moyen pour contrôler toutes les commandes exécutées sur votre slave. Cela m’a permis un jour de trouver la source d’un problème. Un client mal configuré venait mettre à jour un slave et faisait ainsi planter la réplication.

Dans une architecture MySQL nous retrouvons un maître (M) pour les écritures et plusieurs esclaves (S) pour la lecture. MySQL ne permet pas l’extensibilité en écriture mais en lecture, d’ou la notion de “Shards”, un ensemble de plusieurs blocks (M-S). L’idée est de partitionner vos données. Mais ceci est une autre histoire. Pour accéder à vos esclaves, nous utilisons une VIP/Load Balancer en “round robin”. Vos applications étant ainsi re-dirigées vers un esclave de façon aléatoire.
La question est maintenant: Comment puis je maintenant enlever un esclave de la rotation?
Tout va dépendre de ce qui vous utilisez comme HW / SW.

En tout cas, ce que nous voulons:

• Ne pas arrêter l’esclave: pour pouvoir travailler dessus sans pour autant le laisser en rotation
• Ne pas utiliser skip-networking: pour ne pas avoir à redémarrer MySQL

Donc nous allons devoir couper la vérification en 2 parties:

• 1. Server OK
• 2. MySQL OK

Votre VIP devra sortir le serveur MySQL de la rotation si (1) ou si (1) ET (2). Un simple stratagème est de mettre un serveur http avec un fichier X.html. Si le fichier X.html est présent alors le serveur est ok.
Ensuite vous pouvez vérifier la connectivité MySQL en elle même.