La version 5.0 de la base de données MySQL est sortie en version stable en octobre 2005. Cela faisait donc plus de 3 ans que les utilisateurs attendaient une nouvelle version stable et le bébé est arrivé le 27 novembre dernier (en version 5.1.30) en apportant pas mal de nouveautés.
Cet article très complet du site Heise Online décrit les principales (partitions des bases sur plusieurs disques, gestionnaire d'évènements, amélioration des fonctions de réplication, log dans les tables, etc).
Tout semble donc bien aller dans le petit monde de MySQL. Certes la nouvelle version s'est faite attendre et ce n'est qu'une version intermédiaire avant le grand saut de la version 6.0 (qui sera basée sur Falcon) mais après tout une base de données est un composant critique et il vaut mieux prendre le temps de proposer un produit stable. Même si cela prend plus de trois ans.
L'ennui se situe justement là. Selon un article posté sur le blog du créateur de MySQL (Michael Widenius) cette version est bourrée de bugs critiques !
Alors que la 5.1 n'est qu'une version "d'attente" de la 6.0 et qu'elle doit donc ne proposer que des nouveautés sans risques et traquer les bugs c'est le contraire qui est constaté par M. Widenius. On trouve dans son post des phrases comme :
* Ne vous attendez pas à ce que tous les bugs critiques que vous aviez rencontré dans la 5.0 soient corrigés dans la 5.1.
* Si vous projetez d'utiliser les nouveautés de MySQL 5.1 alors considérez ces fonctions comme étant en qualité béta.
* Nous avons encore 20 bugs connus provoquant des crashs et des résultats erronés dans la 5.1. Et 35 bugs de plus si on ajoute ceux de la 5.0 qui doivent toujours être présents dans la 5.1. Nous avons également encore plus de 180 bugs sérieux (P2) dans la 5.1.
* Concernant les nouveautés si vous avez un crash d'une table partitionnée alors il est très difficile (parfois impossible) de la réparer.
* Si vous avez un crash serveur pendant un ALTER TABLE sur une table partitionnée alors vous pouvez perdre toutes les données de cette table.
* Le log dans les tables est si lent (-30%) que la fonction est inutilisable pour les sites chargés.
D'après Widenius il y a plusieurs explications à la sortie de cette version pleine de bugs bloquants. D'après lui ce sont les managers et pas les ingénieurs qui prennent les décisions de sortie en fonction d'un planning prédéfini et pas en fonction de la qualité réelle du code. Les équipes ont été éclatés en plusieurs teams et de nombreux "core developpers" on quitté la boite depuis le rachat par Sun. La communauté n'est pas incluse dans le processus de test et elle ne peut pas vraiment remonter les bugs lors du développement.
Widenieus ne critique pas Sun et il déclare même que la faute revient exclusivement au management de MySQL. La seule faute de Sun serait de ne pas avoir changé l'organisation pour corriger les dysfonctionnements. Il plaide finalement pour un mode de fonctionnement "proche de celui de postgreSQL ou la communauté à un rôle moteur dans ce qui est fait et décidé".
Journal La version 5.1 de MySQL est-elle bourrée de bugs ?
30
nov.
2008
# Sun
Posté par thedidouille . Évalué à 10.
Même pas la peine de le prouver, tous les achats externes qu'ils ont fait depuis 2002 se sont traduits par des échecs. Dans le stockage, avec MySQL, avec tarrentella...
Pour y avoir travaillé, la lourdeur, le beniouioui du discourt, le bourrage de crâne pipeau (4 heure de phone call par semaine de la part d'un gars qui sait même pas ce que tu fais, mais qui t'explique comment faire, et surtout qui te canarde dès qu'il peut), les reporting à outrance qui occupe 75% du temps de certains (pour faire bien, même si il n'y a rien à dire).
Entre le manager qui est en mode « je fais dans la finance », où l'on se parle sur le perron des décisions qu'il faudrait prendre pour baratiner les managers Ricains (pour faire un bel « highlight » associé à son report, même si la décision ne rapportera strictement rien à Sun, et que l'ISV aura tout oublié après le déjeuner), et l'ingénieur qui fait de l'optim CPU, qui se casse la tête jusqu'à 20h30 tous les soir pour faire un maximum de support aux clients, qui heureux se mettent à recommander cette plate-forme, et bien c'est le bel esprit, rédacteur de baratin qui est adulé, celui qui trouve facilement une solution à tout problème (en général du genre « tu n'es pas assez corporate »).
J'adore Sun malgré ce que je pourrais leur reprocher à mon égare, je leur souhaite tout le bien que l'on peut imaginer, mais bon dieu, motiver ceux qui en valent la peine, ceux qui vous propose des patches pour améliorer vos produits Open Source, coopérer vraiment avec eux !! je ne parle pas d'Open Office, mais du compilateur, de Swingx, de toutes les autres technos. On ne résout pas une crise avec des beaux slides, mais sur le terrain avec du concret... et virez tous ces corbeaux, vernis de connaissances approximatives, par pitié.
Oufff ça fait du bien. Merci pour ce journal.
Merci.
# La situation de MySQL
Posté par Guillaume Smet (site web personnel) . Évalué à 9.
Accessoirement, rappelons tout de même que MySQL AB avait fait une tentative de RC de la 5.1 il y a environ un an, avant que Sun prenne le contrôle.
Il y a clairement un *énorme* problème technique dans le fait de ne pas arriver à stabiliser une version en 3 ans et, pour moi, la responsabilité du fiasco de la 5.1 est surtout du côté des décisions techniques qui ont été prises (implémentation, volonté d'ajouter trop de choses d'un coup... ?). Le problème de base est vraiment là : impossible de stabiliser la 5.1 (que ce soit parce que c'est effectivement injouable ou parce que tous les efforts sont déjà mis dans la 6). La décision à prendre était grosso modo : soit la publier, soit abandonner et attendre la sortie de la 6 qui reste un truc très très flou pour l'instant. Je comprends un peu la position du management même si c'est une mauvaise décision technique. Accessoirement, ce n'est pas comme si la 5.0 était exempt d'un gros tas de bugs gênants à sa sortie : d'ailleurs, le discours de Monty Widenius est limite encore plus inquiétant pour ceux qui font tourner la 5.0 actuellement : "If you are a new user trying out MySQL for the first time, you should use MySQL 5.1; At least it's better than the MySQL 5.0 community version which has not been updated for some time.".
Pour ce qui est du futur de MySQL, il me semble que Falcon est abandonné suite au départ de son créateur et que l'avenir est plutôt du côté de Maria, le nouveau moteur développé notamment par Monty Widenius. Peu importe sa qualité, il mettra de toute manière un peu de temps à se stabiliser et à faire preuve de la robustesse qu'on attend de la part d'un moteur de SGBD généraliste.
AMHA, MySQL est dans une situation assez critique actuellement :
- même le créateur de MySQL a l'air de croire très moyennement dans la qualité de cette 5.1
- la sortie de la 5.1 ne règle pas le problème de fond de la base actuelle de code : ils ont laissé un paquet de problèmes en suspens et, s'ils étaient triviaux à régler, ça fera longtemps que ce serait fait
- l'avenir semble être à l'adoption d'un tout nouveau moteur qui va forcément faire preuve de jeunesse dans les premiers temps (et l'abandon de Falcon n'arrange pas trop les choses de ce côté-là)
- des forks apparaissent : notamment drizzle dont l'orientation montre assez bien que peu de gens croient dans ce qui a été ajouté dans la 5.1 (et dans la 5.0)
Bref, il semble que la course à l'ajout de fonctionnalités à tout va montre ses limites et qu'il va falloir prendre une autre orientation rapidement. Personnellement, j'aurai préféré que cette version 5.1 soit une version 5.0 où les fonctionnalités existantes de la 5.0 sont toutes implémentées dans leur totalité, sans limites bizarres et sans bugs bizarres. C'était le principal problème AMHA.
Pour l'instant, ils arrivent encore à faire en sorte que ces problèmes ne soient pas trop visibles mais ça commence à se savoir : on commence notamment à avoir des clients qui se posent des questions à ce sujet, ce qui est plutôt pour me plaire.
[^] # Re: La situation de MySQL
Posté par Maclag . Évalué à 2.
Si je suis manager, je cherche (même si je ne comprends pas tout) à savoir un minimum où en est la technique, et si on m'explique toutes les semaines que "ça avance mais on a plein de bugs", il y aura un moment où je tape du poing sur la table et que je lance un ultimatum: toute nouveauté dans laquelle on trouve toujours des bugs dans une série de tests "de base" est immédiatement abandonnée pour cette version.
Les autres fonctionalités entament les procédures de tests "avancées" et tout ceux qui bossaient sur les nouveautés abandonnées se mettent au débuggage de ce qu'on garde.
Enfin, je dis ça, je répète que je ne connais pas grand chose au développement logiciel, et qu'un truc comme MySQL ça doit pas être simple, mais un bon manager ne décide pas de sortir un truc du jour au lendemain, s'il veut respecter une date limite absolument, il le fait savoir AVANT et prend des mesures!
(Je bosse dans les semiconducteurs, et je garantis que si on explique qu'on "a trouvé encore un truc à améliorer ça marche presque" pendant 6 mois alors qu'on est censé avoir des échantillons qualifiés, le directeur technique va nous tomber dessus ça va pas être beau à voir...)
[^] # Re: La situation de MySQL
Posté par Guillaume Smet (site web personnel) . Évalué à 2.
La date limite est archi dépassée en fait et tu es dans une situation inquiétante.
Clairement, la décision du manager est marketing et politique mais elle peut se comprendre compte tenu du contexte. Et elle n'est pas si déconnante vu que Monty dit lui-même que cette version est de toute manière moins buggée que la 5.0 sur les fonctionnalités existantes (et compte tenu du nombre de releases mineures de la 5.0, ça donne une bonne idée de la qualité de la GA de la 5.0).
Dégager les nouvelles fonctionnalités instables, ce n'est pas trop jouable vu que des gens tournent déjà avec cette version (et même si ça semble peu excusable, MySQL est très fautif à mon sens de part la manière de présenter les produits sur le site et la numérotation de version utilisée) et qu'elles sont annoncées depuis deux ans. Et on n'a pas l'impression que les efforts de développement soient vraiment portés sur la 5.1 alors que tout le monde parle déjà de la 6 et de ses nouveaux moteurs qui vont être trop bien. Accessoirement, tu traînes aussi un paquet de bugs majeurs qui ne sont même pas dans les nouvelles fonctionnalités de la nouvelle version...
Bref, pour moi, la décision est vraiment la conséquence directe de la politique de développement et de marketing de MySQL (ajout de fonctionnalités dans un état loin d'être stable sur une branche de release, release de 5.1.x alors que le produit n'est clairement pas fini, annonces trop tôt des nouvelles fonctionnalités qui font qu'il est difficile de se rétracter).
Encore une fois, je défend un peu la position du manager parce que c'est un peu le mauvais flic dans l'histoire. C'est le modèle développement/marketing complet qui est à revoir. Typiquement, ce qui se passe du côté de PostgreSQL est plutôt un modèle du genre à ce niveau (même si du coup, on en paye le prix en marketing).
Rétrospectivement, je suis un peu étonné qu'on fasse tout un pataquès sur la sortie d'une 5.1 avec des bugs alors qu'en fait le message induit par ce que dit Monty est que c'était encore pire sur la 5.0. Il s'agit donc plus d'une politique inscrite dans le temps qu'un truc épisodique. Autant, je comprends presque la décision pour la 5.1 compte tenu du contexte, autant c'est beaucoup plus discutable pour la sortie de la 5.0, où le contexte était très différent.
[^] # Re: La situation de MySQL
Posté par Maclag . Évalué à 3.
En fait, si je comprends bien, il y a des corrections de bugs par rapport à la 5.0 (donc, c'est bien de migrer), mais faut surtout pas toucher aux nouveautés en prod!
Sinon, désolé, je peux pas m'empêcher de la faire:
Les nouveautés de MySQL 5.1, c'est le CPE du logiciel libre:
"Nous avons intégré de nouvelles fonctions dans MySQL 5.1, nous vous demandons de ne pas vous en servir..."
---->[ ]
# Obligatoire
Posté par timid . Évalué à 10.
[^] # Re: Obligatoire
Posté par tanguy_k (site web personnel) . Évalué à 4.
SQLite est apparemment limité (dixit les devs d'Amarok) et il est préférable d'utiliser MySQL embedded pour ce type d'utilisation.
[^] # Re: Obligatoire
Posté par windu.2b . Évalué à 9.
Parce que j'ai en effet vu les dév. d'Amarok refuser SQLite au profit de MySQL embedded, mais je me demande bien ce qui a pu les gêner à ce point ? Amarok n'est quand même pas une application ayant des besoins pharamineux en stockage de données...
De toute façon, je m'étonne surtout de ne pas les voir utiliser Nepomuk pour le stockage des métadonnées. Ça serait tout de même mieux intégré à KDE 4 (et on pourrait ainsi modifier lesdites métadonnées via autre chose qu'Amarok, comme Dolphin par ex.).
[^] # Re: Obligatoire
Posté par herodiade . Évalué à 10.
Je ne sais pas si on peut vraiment parler de « limites ». En pratique, les objectifs et cas d'utilisation de SQLite et de MySQL Embedded sont très différents.
SQLite s'efforce avant tout d'être une bibliothèque petite, compacte et le plus légère possible (en termes de ressources à l'execution comme en termes d'occupation disque). Richard Hipp, le développeur principal de SQLite, répète souvent que l'embarqué (le vrais, sur des machines où même la place sur disque est précieuse au KB près) est la priorité de SQLite, et qu'il est le secteur qui finance la plupart des développements. Par ailleurs SQLite est dans le domaine public, ce qui rend cette bibliothèque adaptée aux applications propriétaires et aux applications libres utilisant autre chose que la GPLv2 (licence de MySQL Embedded).
MySQL Embedded, en revanche, n'est pas réellement un système destiné à l'embarqué au sens strict (quoi que le nom laisse penser), mais plutôt une version « desktop » de MySQL. Les choix sont donc naturellement différents de ceux de SQLite ; ME peut utiliser, par exemple, un cache en RAM, ce qui a un effet très positif sur les performances pour les requêtes en lecture. Il offre aussi l'option de ne pas faire de fsync() après commit des données, ce qui permet de laisser à l'OS (au thread pdflush du noyau) l'opportunité d'aggréger les écritures de façon optimale, au risque de perdre 1 ou 2 secondes de données (probablement un bon compromis pour le type d'utilisation d'Amarok ; remarquez que ce fsync() obligatoire a posé de gros problèmes aux développeurs de Firefox lorsque ce dernier a adopté SQLite pour tout stocker).
En bref, MySQL Embedded cible les applications desktop, et Amarok est une application desktop, pour laquelle, en outre, la licence GPLv2 n'est pas un obstacle.
> Amarok n'est quand même pas une application ayant des besoins pharamineux en stockage de données...
Certes non, mais les développeurs ont pourtant rapidement du faire face à des problèmes de performances insurmontables avec les grosses collections. D'après leurs dires, les performances sont devenues très correctes après qu'ils aient décidé d'adopter MySQL Embedded comme principal (et en fait, seul) moteur de stockage.
[^] # Re: Obligatoire
Posté par lem__mel . Évalué à 0.
ME peut utiliser, par exemple, un cache en RAM, ce qui a un effet très positif sur les performances pour les requêtes en lecture
si l'on regarde http://www.sqlite.org/pragma.html, on y découvre le pragma "synchronous" qui permet de faire la même chose : ne pas synchroniser sur le disque[1].
Pour les usages et les tests que j'en ai fait (taille de données faible : même pas 10 000 lignes à vue de nez), SQLite est terriblement véloce et même plus que l'ami MySQL (même sur les vues, SQLite est plus rapide) ; par contre le SQL de SQLite est plus limité (gestion des dates, jointures et update en même temps, etc).
[1] il suffit, si le besoin de sécurité des données est important, de synchroniser soit-même plus tard
[^] # Re: Obligatoire
Posté par Bozo_le_clown . Évalué à 6.
pharamineux
Tout à la fois pharaoniques et faramineux ?
[^] # Re: Obligatoire
Posté par patrick_g (site web personnel) . Évalué à 5.
http://atilf.atilf.fr/dendien/scripts/tlfiv5/visusel.exe?11;(...)
"Certains dict. indiquent l'anc. graph. pharamineux en soulignant que l'étymol. ne la justifie nullement (cf. ROB. [qui rappelle que E. Rostand l'emploie dans Cyrano de Bergerac I, 4]"
[^] # Re: Obligatoire
Posté par Bozo_le_clown . Évalué à 3.
Dans ce cas, toutes mes confuses.
[^] # Re: Obligatoire
Posté par Sylvain Sauvage . Évalué à 5.
(En tout cas, c’est pas pire que les nouvelles…)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.