Les annonces faites par Kaj ont secoué un peu la communauté avec des réactions assez forte de ses membres actifs. Je vous laisserez les lire en détails sur son blog.
Mais voila l’idée générale:

• Les patchs et les nouvelles fonctionnalités ne seront plus appliqué à la GA mais attendront la version suivante.
• 2 GA par an pour ce qui est des binaires
• pour les nouvelles versions 1 GA par mois jusqu’à maturation
• 4 GA par an pour ce qui est des sources
• Les sources des versions “entreprise” ne seront disponibles que pour les clients payant

Suite à cela pas mal de réactions, en autres de la part de Mike et …

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:

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

Aujourd’hui j’ai reçu un message d’un collègue qui était surpris de voir que son “datafile” InnoDB gardait la même taille aprés avoir effacé des tables ou des éléments de ses tables.
C’est tout à fait normal! Toutes les bases de données marchent de la même facon. Un tablespace s’agrandira tout seul si vous le créez en mode autoextend et ce sous MySQL mais aussi Oracle, IBM DB2,… Si vous n’activez pas la fonction autoextend quand la base voudra allouer de la place, vous verrez une belle erreur.

La question est pourquoi? Performances!

Pour gagner en performances, vous voulez que votre base pré alloue de l’espace disque, des blocks de data pour vous. Nous parlons alors d’extend. Vu ces conditions veut on vraiment désalloué des entends pour les réallouer ensuite? La réponse est non!

Comment alors récupérer de l’espace? La seule solution est d’exporter les data, d’effacer les …

Si vous jouez un peu avec MySQL vous devez déjà connaitre la commande SHOW STATUS. Elle vous donne un snapshot de tous les compteurs interne de MySQL. Ces compteurs traquent des événements précis, par exemple:

mysql> show status like ‘Com_select’;
+—————+————+
| Variable_name | Value |
+—————+————+
| Com_select | 2293615720 |
+—————+————+
1 row in set (0.00 sec)

Voila le nombre de select qu’il y a eu sur ce server, 2.3 milliards… oups…

mysql> show status like ‘Questions’;
+—————+———–+
| Variable_name | Value |
+—————+———–+
| Questions | 533719732 |
+—————+———–+
1 row in set (0.00 sec)

‘Questions’ est le nombre de requêtes et commandes envoyées au serveur et devrait donc être logiquement la somme …

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 …

Aujourd’hui fut la journée des ‘too many connections’. En effet pas loin de 3 applications ont planté du fait que le nombre maximum de connexions MySQL avait été atteint. Le message d’erreur est très parlant. Comment est ce possible? mysqld autorise max_connections+1 clients à se connecter. Le ‘+1′ est une extra connexion réservée aux comptes ayant le privilège SUPER. Donc si votre user applicatif à ce privilège, vous vous retrouvez bloqués. Prenez comme principe d’avoir les privilèges minimaux pour vos utilisateurs, INSERT, UPDATE, DELETE et SELECT suffisent largement.

La valeur par défaut du paramètre est de 100.


mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 100 |
+-----------------+-------+


Donc à vous de connaître vos besoins …

Je tenais à remercier Lenz pour le clin d’oeil sur son blog. Comme il le dit si bien amis MySQL fan, proposer sans faute votre flux.
Plus on est de fous pour on rit.