(<- précédent)

Le programmateur d’évènements

Pouvoir automatiser ses tâches de manière fiable et simple est le rêve de tout administrateur de base de données. Le programmateur d’évènements (Event Scheduler) est un planificateur de tâches (CRON-like) embarqué dans MySQL 5.1.

Il est alors possible d’exécuter, de façon récurrente ou unique, des requêtes, en fonction de la date et de l’heure.

L’évènement se crée avec la commande CREATE EVENT.

CREATE EVENT nom_evenement ON SCHEDULE
      <moment> DO <code_sql>

L’évènement peut être lancé une seule fois (AT) ou de manière répétitive (EVERY)

…

“Installez-moi une configuration MySQL composée d’un master et deux slaves, vous avez 15 secondes. Top chrono”…

Non, ça n’est pas la dernière énigme à la mode pour rentrer chez Google mais plutôt une question qui pourrait devenir presque banale pour un entretien d’embauche pour un DBA MySQL à l’avenir, qui sait ?

Face à un tel défi, trois solutions :

- La fuite (mais faites une croix sur la “recommandation” Linkedin)
- Le kernel panic
- MySQL Sandbox !

Bien vu, MySQL Sandbox est la réponse la plus stratégique pour la poursuite de votre carrière.

Giuseppe Maxia (dont le blog figure dans notre blogroll, allez y jeter un oeil) est l’auteur de cet outil vraiment très pratique.  Que propose t-il ?

L’idée est d’automatiser l’installation de plusieurs serveurs MySQL sur une même machine. Rien que nous ne puissions faire manuellement c’est …

“Un schéma vaut mille mots”, l’idée est toute simple : tenter d’exprimer en un schéma une idée précise concernant MySQL.

Il s’agit ici du type de schéma que nous avons tous griffonné pour un collègue ou soi-même afin de clarifier un processus : pas de powerpoint, pas de visio mais un brouillon, un stylo, et hop.

La règle du jeu : le schéma doit dans l’idéal se suffire à lui-même et ne pas forcément engendrer un billet qui ferait office de “légende”… Néanmoins quelques mots d’explications ne sont parfois pas de trop, même à côté d’un schéma, donc tout est possible.

La “richesse” des schémas/dessins viendra également des commentaires qui leur seront attribués, de la même façon que les commentaires enrichissent les billets d’un blog en ajoutant au billet initial les questions/retours d’expérience des lecteurs. Je vous encourage donc à poster des commentaires les …

Lorsque vous faites un SHOW SLAVE STATUS pour savoir l’état d’un de vos slaves dans votre chaîne de réplication, vous avez cet intéressant paramètre Seconds_behind_master, ceci évidemment si vous utilisez MySQL 4.1 et plus. Sur un serveur j’ai eu la désagréable surprise de voir cette valeur alterner constamment entre 0 et 2 heures…Humm? Ceci m’a poussé à regarder plus en détail le calcul de cette valeur.

Quand un slave se connecte au master, par la entendez le Slave I/O thread, il enregistre la valeur dm = SELECT UNIX_TIMESTAMP() ce qui revient à connaître la date actuelle du master (dm: date master) puis fait la même chose sur lui même ds = SELECT UNIX_TIMESTAMP() (ds: date slave). De la il calcule la différence D = ts - tm.

Dans les log de réplication (binlog) sont enregistrés les dates d’exécutions de chaque requête. Ainsi lorsque le Slave SQL thread rejoue ces même requêtes, il calcule:

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. …

Qui n’a jamais utilisé MySQL sans la réplication? La réplication permet à votre application de supporter un nombre de lecture beaucoup plus important. Les updates se font sur une base de donnée “maître” (master) et sont ensuite répliquées sur plusieurs “esclaves” (slaves). Le maître n’a pas à supporter les requêtes venant de clients qui sont gérées par les esclaves. Un autre jour je rentrerai plus en détails la dessus mais en résumé, le maître écrit dans des fichiers toutes les requêtes qui ont modifié ses informations (insert, update et delete). Les slaves viennent à leur tour récupérer ces fichiers (binary logs) et les “copie” localement (relay logs) avant de les rejouer.

Il est conseillé en général de dédier un disque pour ces fichiers car beaucoup d’écriture entraîne une baisse de vos performances. Dans le cas qui nous intéresse, l’activité du CPU m’a très étonné. En effet jusqu’à …