dbnewz

Un événement MySQL en Europe à ne pas rater est le développeur meeting qui aura lieu le 20,21 septembre 2007 à Heidelberg en Allemagne, prés de Francfort. Je vous laisse lire le post de Kaj à ce sujet. C’est avec un grand plaisir que je viens d’apprendre que mes amis Jérémy et Eric de Proven Scaling seront de la partie.
Si vous avez besoin de conseils, de formations c’est le moment d’en profiter, ce n’est pas souvent que ces experts mondiaux sont parmi nous. Ils sont prêt à se déplacer partout en France et en Europe soit avant soit après le meeting. Vous pouvez soit les contacter directement soit me laisser un message.

Après la traduction de PlanetMySQL en français, le prochaine étape serait logiquement de mettre en place des rencontres Meetup en France. Je viens d’en découvrir un sur Paris, et pense en démarrer un autre sur Grenoble, pourquoi pas après tout. Lundi je m’envole pour Toronto et j’en profiterai aussi pour participer au meetup local. Pour le compte de ma société je donne des formations MySQL un peu partout. Après Grenoble et Londres, me voila en partance pour le Canada. Les formations suivantes devraient m’emmener au Brésil et en Asie.

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.