La conférence Oracle Open World est désormais l’occasion pour Oracle de diffuser des infos sur les nouveautés à venir pour MySQL.
Et le moins que l’on puisse dire, c’est que ça bouge(ra) pas mal !

Il semblerait que la prochaine version 5.6 soit en bonne voie pour devenir GA prochainement, à vos marques…

C’est ainsi l’occasion de faire un petit récap des annonces les plus intéressantes concernant la version 5.6 (ça n’engage que moi et il n’y a pas d’ordre précis)  :

• Optimisation de l’indexation et de la manière dont l’optimizer appréhende les index (Index Condition Pushdown)
• Possibilité de tracer les “choix” réalisés par l’optimizer
• Possibilité de faire des EXPLAIN de commandes DELETE, UPDATE et INSERT
• Les vues “matérialisées” arrivent et ce sera valable pour les tables dérivées et les sous requêtes (et on pourra y mettre des index !)
• La sauvegarde/restauration du cache InnoDB (buffer pool size) sera possible (déjà dispo avec Percona server)
• Statistiques InnoDB persistantes !
• Réplication multi threads (cool)
• (Ajoutez les votres) …

Sachez également que Oracle proposera prochainement (enfin !) de nouvelles certifications pour les DBA MySQL que nous sommes.

Si vous souhaitez aller plus loin, voici quelques liens utiles concernant les annonces faites hier à la OOW2011 :

• http://blogs.oracle.com/MySQL/entry/new_development_milestone_releases_certifications
• http://blogs.oracle.com/MySQL/entry/more_early_access_features_in
• http://palominodb.com/blog/2011/10/03/liveblogging-oow-state-dolphin
• http://oysteing.blogspot.com/2011/10/bacthed-key-access-speeds-up-disk-bound.html
• http://yoshinorimatsunobu.blogspot.com/2011/10/testing-mysql-563-network-performance.html
• http://glebshchepa.blogspot.com/2011/10/optimizer-new-explain-for-data.html
• http://ronaldbradford.com/blog/oracle-open-world-presentations-2011-10-04/
• (Vos liens)…

N’hésitez pas à commenter concernant ces nouveautés et donner vos impressions et liens !

J’avance sur cette série d’articles que j’avais un peu laissé tomber :-)
Retrouvez les deux premiers épisodes Oracle & SkySQL en cliquant sur les liens suivants :

• Tour d’horizon de l’offre Oracle MySQL
• Tour d’horizon de l’offre SkySQL

Je vous propose cette fois un tour d’horizon des offres plus confidentielles (en France) de fromdual et Percona sous la forme d’un tableau comparatif des différentes offres :

Je ferai un prochain billet avec un tableau comparatif de toutes les offres d’Oracle, SkySQL, Percona et frondual.

Bon week-end.

Pour tous les fans de MySQL, il y aura du beau monde les 24 et 25 octobre prochains à la conférence Percona Live London 2011.
Il y a au moins 10 bonnes raisons de se rendre à cette conférence : http://www.mysqlplus.net/2011/09/22/percona-live/

Profitez-en, les tarifs spéciaux “premiers inscrits” sont encore en vigueur jusqu’au 28 septembre prochain : http://www.eventbrite.com/event/1909670877/eorg/

J’en profite pour vous signaler qu’un groupe LinkedIn a été créé à cette occasion pour la communauté francophone : http://www.linkedin.com/groups/Percona-Live-London-2011-For-4094253

N’hésitez pas à vous inscrire et à partager autour de cette conférence.

Vous pouvez également télécharger le PDF à emporter (confectionné par mes soins !) :  PLL2011.pdf

Rendez-vous à Londres.
Bonne fin de semaine.

Cédric

Il est grand temps pour moi d’aller voir si le soleil m’attend quelque part, une pause s’impose !
MySQL+ reprendra donc une activité normale d’ici quelques semaines, d’ici là, je vous invite à lire ou relire les articles les plus populaires :

• Howto : XtraDB sauvegarde votre cache
• Avez-vous migré vers la 5.5 ? découvrez le paramètre innodb_io_capacity
• Profitez de l’été pour tester MMM ou pour migrer vos bases Oracle vers MySQL
• Promis, je finirai mon tour d’horizon sur les offres de support MySQL avant Noël !
• Enfin, il n’y a pas que l’explain dans la vie

Si le coeur vous en dit, n’hésitez pas à laisser un commentaire sur ces articles.

Si vous ne l’avez jamais fait, je vous propose de lire l’à propos de ce site : http://www.mysqlplus.fr/a-propos/

N’oubliez pas de me suivre également sur twitter, de vous abonnez au flux RSS ou par email.

Je n’ai plus qu’une seule chose à écrire : Bonnes vacances !

J’utilise la commande OPTIMIZE depuis longtemps, en particulier pour des problèmes d’espace disque.
Cette commande permet de réaliser une sorte de réorganisation de vos tables et index, pour MyISAM et InnoDB.
Et elle est particulièrement utile lorsqu’une table est vidée partiellement ou complètement afin de récupérer l’espace ainsi libéré (mais toujours occupé par le fichier physique sur disque).

J’ai récemment découvert un bug pouvant remettre en cause cette méthode pour certaines versions de MySQL (InnoDB), je vous laisse juger par vous même :

Création d’une table avec une colonne auto-incrémentée :

mysql> use test
Database changed
mysql> create table test_optimize (id int(8) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (id)) engine=InnoDB;
Query OK, 0 rows affected (1.09 sec)

mysql> insert into test_optimize values (1),(2),(3),(4);
Query OK, 4 rows affected (0.28 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> show table status like ‘test_optimize’G
*************************** 1. row ***************************
Name: test_optimize
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 4
Avg_row_length: 4096
Data_length: 16384
Max_data_length: 0
Index_length: 0
Data_free: 0
Auto_increment: 5
Create_time: 2011-07-12 10:21:28
Update_time: NULL
Check_time: NULL
Collation: latin1_swedish_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.02 sec)

4 lignes sont insérées dans cette table, l’auto incrément est à 5.

Suppression de toutes les lignes de la table puis OPTIMIZE :

mysql> delete from test_optimize;
Query OK, 4 rows affected (0.00 sec)

mysql> select count(*) from test_optimize;
+—————+
| count(*) |
+—————+
|        0 |
+—————+
1 row in set (0.00 sec)

mysql> optimize table test_optimize;
mysql> show table status like ‘test_optimize’G
*************************** 1. row ***************************
Name: test_optimize
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 0
Avg_row_length: 0
Data_length: 16384
Max_data_length: 0
Index_length: 0
Data_free: 0
Auto_increment: 1
Create_time: 2011-07-12 10:23:39
Update_time: NULL
Check_time: NULL
Collation: latin1_swedish_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)

Suite à la suppression de toutes les lignes et le passage d’une commande OPTIMIZE, l’auto-incrément est repassé à la valeur 1 !
Il s’agit d’un bug référencé par MySQL pour InnoDB : http://bugs.mysql.com/bug.php?id=18274

Pour éviter ce problème, il sera nécessaire de passer aux versions suivantes de MySQL : 5.1.55, 5.5.9 ou 5.6.1

Je vous laisse juger des conséquences que peut avoir ce bug dans votre contexte.
N’hésitez pas à réagir et donner votre point de vue dans les commentaires.

Bonne semaine.

Bon, je fais un peu de buzz !
Je n’ai pas pour habitude de parler de Virgin ici mais j’y étais, j’assume :

Un petit post pour présenter un outil que j’ai découvert dernièrement : mpstat
J’ai pour habitude d’utiliser vmstat afin de visualiser rapidement la charge sur un serveur mais mpstat peut séduire par sa simplicité.

L’affichage de mpstat (toutes les secondes) pour tous les CPU : mpstat 1

Il est également possible d’afficher les infos d’un CPU particulier : mpstat -P 2 1

On y retrouve les informations essentielles :

• Le CPU monitoré (ALL pour tous les CPU)
• La consommation CPU user/system et iowait
• Des compteurs concernant les “interrupts”

Un manque important je trouve par rapport à vmstat est l’absence d’information sur la file d’attente processeur (colonnes r et b de vmstat).
Bref, rien de révolutionnaire mais un outil pouvant être utile pour du monitoring, notamment pour sa fonctionnalité permettant d’avoir les infos d’un processeur particulier.

Je vous laisse tester par vous même et me dire si vous avez l’intention de l’adopter…

Un flush logs essentiellement consacré à MMM (multi-masters replication)

En effet, plusieurs acteurs importants de la mysqlsphère ont exprimé cette semaine leurs difficultés avec cet outil remettant même en cause une utilisation possible en production.

J’avais moi même exprimé il y a quelques temps mon sentiment sur cet outil : Pourquoi-mmm-ne-fait-pas-ce-que-jaimerais-quil-fasse/

Les réactions à ces articles sont diverses et variées mais ce soudain intérêt pour cet outil est à mon avis révélateur d’une tendance à vouloir aller plus loin avec MySQL aujourd’hui.
En effet, la réplication est très utilisée avec MySQL et les outils permettant de rendre transparent la promotion d’un slave en master sont rares et parfois peu fiables. Le fait est que chacun a finalement pris le pli de développer ses propres outils ou d’écrire des procédures de promotion manuelle.

Je dis que c’est révélateur d’un changement de comportement mais également de la façon dont on utilise désormais MySQL pour des projets de plus en plus critiques en production. Il est donc normal de se heurter aux mêmes difficultés que l’on a pu rencontrer avec les autres SGBD et de tenter de trouver des solutions plus ou moins pertinentes.

La seule chose qui reste un peu flou après la lecture de ces articles est de savoir quelles solutions pertinentes mettre en oeuvre pour faire du multi-masters ?
Finalement, j’ai tendance à penser que pour l’instant, la réplication MySQL n’est pas conçue pour ça, au moins jusqu’à la version 5.1 (Des améliorations significatives arrivent en 5.5 et 5.6 pour la réplication).

Il faut donc peut-être se poser la question différemment : Est-il raisonnable de faire du multi-masters avec la réplication MySQL aujourd’hui ?

Je n’ai pas de réponse définitive à cette question et vous laisse vous faire votre propre opinion à travers les différents articles publiés dernièrement sur le sujet :
( Lisez aussi les commentaires, ils sont également très intéressants )

• Ca commence avec cet article de Baron schwartz qui évoque des bugs, un manque de documentation et d’éventuelles alternatives à MMM : What’s wrong with MMM ?
• Shlomi Noach continu dans la même voie : Problems with MMM for MySQL
• Ensuite viennent deux articles concernant la haute disponibilité avec MySQL : The different ways of doing HA in MySQL & What kind of High Availability do you need ?

Pour le reste de l’actualité MySQL, j’ai selectionné les news suivantes pour cette semaine (on reste un peu dans le monde de la réplication) :

• Sur le blog de Pythian, attention quand vous purgez vos logs binaires dans le cadre d’une réplication : Never purge logs before slave catches them !!
• Giuseppe Maxia fait un petit benchmark de la réplication semie synchrone avec MySQL 5.5 : Benchmarking semi synchronous replication
• MONyog 4.5 est de sorti avec son lot de nouveautés très intéressantes
• Stéphane fait une brillante démonstration du coût des index inutiles (via dbnewz)
• Si vous vous retrouvez avec des fichiers .ibd orphelins, les solutions sont ici : Connecting orphaned .ibd files

C’est tout pour cette semaine. N’hésitez pas à partager vos expériences sur MMM !

Il y a divers paramètres de timeout MySQL :

Mais celui qui m’intéresse aujourd’hui, c’est le wait_timeout (ou le interactive_timeout en fonction de comment l’on se connecte).
Ce timeout permet à MySQL de fermer une connexion automatiquement en cas de non-activité de la part de l’utilisateur pendant le temps défini par ce paramètre (par défaut 28000 secondes).

Le problème que je souhaite relever aujourd’hui arrive lorsque ce timeout est positionné à une valeur faible (10 secondes par exemple)

En effet, dans ce cas, il peut arriver que ce timeout engendre de graves conséquences, explications :

(Le timeout est positionné à 10 secondes par exemple)

Vous vous connectez via le client MySQL standard pour passer une requête de suppression de données via une transaction (pour bypasser l’autocommit) :

• Début de la transaction : mysql> start transaction;
• [ Ici vous attendez plus de 10 secondes car un collègue vous fait une démo de la dernière appli iphone à la mode... ]
• Vous lancez la suppression : mysql> delete from table_super_critique;

C’est ici que les problèmes commencent car étant distrait par votre collègue, vous avez oublié la clause where du delete ! (aïe…)
En effet, lors du passage de la commande de delete, MySQL a renvoyé le message suivant :

ERROR 2006 (HY000): MySQL server has gone away

No connection. Trying to reconnect...
Connection id:    98
Current database: test

Query OK, 33698541 rows affected (0.01 sec)

Ce qui signifie simplement que la connexion a été perdue et que MySQL a relancé la dernière commande soumise, soit, le delete incomplet !
Vous tentez alors désespérément de faire une annulation tandis qu’une goutte de sueur coule le long de votre front :

• mysql> rollback;
• mysql> select * from table_super_critique;

Perdu, le select retourne cruellement 0 ligne !

Et c’est normal, le start transaction a été perdu lors de la perte de connexion à la base, l’annulation de la transaction n’est donc plus possible.
Les 33 millions de lignes de votre table super critique viennent de s’évaporer, c’est le moment de prendre des vacances…

Bon week-end
Cédric

Suite à l’article publié la semaine dernière sur ArKZoYd, je me suis dit qu’effectivement il y a des petits trucs que l’on se traine pendant des années sans avoir le temps de chercher une solution.
J’en profilte donc pour partager à mon tour une petite astuce pour le copier/coller dans Vi.

Avec Vi, coller du texte ressemble parfois à ça :

La faute à l’indentation automatique !
En effet, si il y a des espaces devant vos lignes, ce qui arrive souvent dans les scripts pour une meilleure lisibilité, toutes les lignes seront indentées.

La solution : set noai

L’instruction set noai permet de désactiver l’indentation automatique et ainsi avoir une copie fidèle du texte d’origine.

Je sors du contexte bases de données mais pas tant que ça, combien de DBA utilisent Vi au quotidien ?!

Bonne fin de semaine