Slashdot Log In
MySQL 5.1 Released, Not Quite Up To Par
Posted by
ScuttleMonkey
on Mon Dec 01, 2008 01:28 PM
from the time-to-fix-the-org dept.
from the time-to-fix-the-org dept.
Mad Merlin writes "It's no secret that MySQL 5.1 has been a long time in the making, with the first beta release being in Nov 2005, but MySQL 5.1.30 has finally been released as GA. MySQL users can expect new features such as table/index partitioning, row based replication, a new plugin architecture, an event scheduler and a host of performance improvements from 5.1." Monty also had a blog post outlining some of the challenges faced in 5.1, including crashing bugs and a beta quality to most new features.
Related Stories
[+]
MySQL Founder Monty Quits Sun (Or Not) 148 comments
Paul Boutin writes "A reliable source tells Valleywag that MySQL inventor Michael Widenius, better known as Monty, has resigned from Sun. Sun bought Monty's MySQL company in a billion-dollar deal last January. Brian Aker, who forked the Web 2.0-friendly Drizzle SQL database (and former Slashdot engineer!), remains at Sun." Kaj Arnö and Sheeri Cabral share their thoughts.
[+]
Sun's Mickos Is OK With Monty's MySQL 5.1 Rant 155 comments
narramissic writes "Back on November 29, MySQL developer Michael Widenius trashed Sun's decision to give MySQL 5.1 a 'generally available' designation in a now-infamous blog post. Widenius warned users to be 'very cautious about MySQL 5.1' because 'there are still many known and unknown fatal bugs in the new features that are still not addressed.' And now we get Sun's response. In an interview Monday, Marten Mickos, senior VP of Sun's database group, said, 'I learned over many years about the benefits and the painfulness of absolute transparency in open source. A little bit of debate never hurts. This is part of being an open-source company. ... People are free to blog about what they want.' Doubtless, this will do nothing to end the debate over whether Widenius will follow fellow MySQL co-founder David Axmark's lead and leave Sun."
[+]
MySQL Co-Founder Monty Widenius Quits Sun 140 comments
BobB-nw writes "Michael 'Monty' Widenius, the original developer of the open-source MySQL database, has left Sun Microsystems and is starting his own company, Monty Program Ab, he said in a blog post Thursday. Widenius and Sun had a slightly rocky relationship since the vendor bought MySQL last year for $1 billion. In a much-discussed November blog post, he trashed Sun's decision to give MySQL 5.1 a 'generally available' designation, saying it was riddled with serious bugs.
Meanwhile, Monty Program Ab will be 'a true open-source company,' with only a small number of employees who 'strive to have fun together and share the profit we create.' The company will work on the Maria project, a storage engine Widenius and others developed, he wrote.'"
[+]
Five Questions With Michael Widenius 71 comments
volume4 writes "With two MySQL execs leaving Sun in the last week, the internet is buzzing about what is going on at Sun, what is the future of MySQL and what lies ahead for Michael Widenius. Over at Open Source Release Feed, Widenius spoke candidly regarding his split from Sun, the future of MySQL, Monty Program AB, and the open source ecosystem in general."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
"Fair and balanced" summary?? (Score:3, Interesting)
Ryan Thiessen, a long-time 5.1 user, strongly rebuts Monty on his blog. [hideandsql.com]
Re:"Fair and balanced" summary?? (Score:5, Insightful)
Obviously 5.1 is not a perfect release. Quality is critically important to a database and I hope MySQL/Sun takes note of Montyâ(TM)s concerns, ...
However in my opinion MySQL 5.1 a very good release, long ready for general production usage.
You call THAT a rebuttal? My goodness... it no wonder MySQL sucks if he can admit on the one hand it's bugridden (not in those words, sure) and then say at the same time, it's ready for general production usage. What the hell does that mean?! It just makes me ANGRY to think people like this are DBAs! Does he mean to suggest your "general production usage" server is OK with lost rows and table corruption... if the chances of it happening are rare enough? Does he mean to suggest "general production usage" is a separate category from "people who use the advertised features of the product?" Seriously.... arrrrgh..... I think I'm having a stroke, I need to go take a valium or something.
Parent
Re:"Fair and balanced" summary?? (Score:4, Insightful)
What you responded to was an out of context quote, which by omission seemed to combine two sentences. In context my words might be less valium-inducing to you.
"""
Obviously 5.1 is not a perfect release. Quality is critically important to a database and I hope MySQL/Sun takes note of Montyâ(TM)s concerns, especially about core developers working on fun new projects like Drizzle and leaving relatively inexperienced developers fixing bugs in their core business product.
However in my opinion MySQL 5.1 a very good release, long ready for general production usage. Definitely test it before you use it, like you should also test new kernels, Apache versions, distribution releases, etc. But do not alow this sensationalist blog post to overshadow what should be considered a solid engineering accomplishment by the MySQL team.
"""
Parent
Re:"Fair and balanced" summary?? (Score:4, Funny)
...it no wonder MySQL sucks if he can admit on the one hand it's bugridden (not in those words, sure) and then say at the same time, it's ready for general production usage.
I think that just brings it up to the major leagues. I mean Oracle managed to ship production versions of its DB with developer's home directory hardcoded into startup script [oracle.com] which without modifications would not allow you to start DB. How does something like THAT pass QA?
-Em
Parent
Re:"Fair and balanced" summary?? (Score:5, Funny)
>How does something like THAT pass QA?
That's REALLY unfair to blame Oracle for QA processes... they outsource SQA process, so it's a SUPPLIER problem.
Parent
Re:"Fair and balanced" summary?? (Score:5, Interesting)
It sounds like MySQL could benefit from a more debian-like release criteria [debian.org].
Parent
Re:5.0? that so? (Score:4, Insightful)
Parent
Re:5.0? that so? (Score:5, Insightful)
If you allow your users direct access to SQL and rely on SQL permissions you probably shouldn't. Most MySQL setups have no way of allowing untrusted users to run SQL directly so they can't run a drop table statement. So yes, if your letting complete strangers run SQL on your database you might want to look somewhere else.
Parent
well (Score:3, Interesting)
maybe they are just trying hard to be more like the commercial enterprise databases. my experience with oracle was that they have a lot more bugs than this - it's just you can't actually find out about them until you call support. Then you find out they have known about it for some time, they just don't publish it. They hide all this stuff instead and only let certain things out.
Re:well (Score:5, Insightful)
I'm not sure what you are trying to say. If we have to play car analogy - lets say both cars engines will fail if you go over 80 kmh on a sunday while wearing blue. One vendor will tell you before you buy the car - the other waits until you've been on the phone with roadside assistance for a couple days. The severity of the issue is the same - it's just how the manufacturer handles it that is different.
To step away from the metaphor for a second - I have had severity 1 service tickets open with Oracle support for over a day that ended up being unpublished bugs that were fixed with a patch that was not available until you knew you had run into the bug. Sev 1 to be clear is production systems down.
I worked on a project with an Oracle consultant who had been on his own before he joined Oracle. I asked why he made the switch and he told me it was for one main reason - so that he would get full access to all the documentation, including all the bugs and open issues.
Parent
Re:well (Score:5, Informative)
To step away from the metaphor for a second - I have had severity 1 service tickets open with Oracle support for over a day that ended up being unpublished bugs that were fixed with a patch that was not available until you knew you had run into the bug. Sev 1 to be clear is production systems down.
I'll second this. We just ran into such a bug when trying to restore a database.
The application connecting to the database was upgraded, and something went wrong when it tried to modify the schema, so we rolled back to the backup taken immediately before the start of this. Normally, this would have been simple, but apparently there's a bug with our version of Oracle that caused the restore to fail. Luckily, it only took an extra couple of hours to work around and we were still in our planned outage window, but it still sucked that it was a bug known to Oracle.
Of course, we didn't hit the Oracle bug in our development and test systems, because the application didn't fail in the schema update on those, thank's to Mr. Murphy.
Parent
Re:well (Score:5, Insightful)
Well, you'd be a fool to buy MS SQL for its enterprise capabilities.
It has its strengths, of course, but it's most important strength is it is the default database slice of the Microsoft deployment stack and is well integrated with Microsoft development tools. For modest projects it provides the kinds of advantages MySQL does in the LAMP stack.
I'm not saying it is a bad product, depending on your needs. Nor am I saying that you can't do "enterprise applications" (whatever those are) if you design around its limitations. I'm just saying that if I weren't developing around a completely Microsoft based solution, I wouldn't give MS SQL a second glance. There are cheaper (open source) solutions on the low end, and more scalable solutions on the high end.
If maximum upward scalability from a PC host starting point was required, I'd go with Oracle. The fit on the low end is a bit awkward, but it's workable. You've got to be careful when you license Oracle because you can spend too much money very easily, but if you know what you're doing Oracle is scalable and cost-efficient. If you don't know what you're doing, that's a different affair altogether.
Parent
Wow (Score:5, Insightful)
Impressive, now MySQL can have features other databases (PostgreSQL among others) have had for *years*. I've never understood; people like MySQL because it is "light", "simple", "easy", blah, blah.... and yet they add all these enterprise features that then everyone will laud about how MySQL is "growing up" or some such. MySQL is one of the best examples of self redefined success I think I've ever seen.
If you want these features why not use a database that has had them for a long time, where they are better tested, and possibly get better performance under concurrent load as a side benefit.
Re: (Score:3, Insightful)
In addition, since MySQL got so popular so quickly, develope
Re:Wow (Score:5, Informative)
MySQL is very easy to use and configure the first time. Postgres isn't nearly as simple
I've heard this a few times. I've installed PostgreSQL on Windows, Linux, FreeBSD and OpenBSD. Every time, the process has been:
How does MySQL simplify this?
Parent
Re:Wow (Score:4, Informative)
.... Things like "SHOW TABLES" are either considerably more difficult in Postgres or harder to find out. ....
More difficult? Harder to find out? Consult help by typing \? and you will see this:
[snip]
Informational
\d [NAME] describe table, index, sequence, or view
\d{t|i|s|v|S} [PATTERN] (add "+" for more detail)
list tables/indexes/sequences/views/system tables
[snip]
Then type \dt to show the tables. To me that does not present it seld as more difficult or hard to find out.
Parent
The first time I used MySQL... (Score:5, Interesting)
I've used MySQL for years...
The same thing in MySQL would have taken me thirty seconds now, and no more than 15 minutes when I was starting out. With Postgres, it took me upwards of 20 minutes when it should have taken much less time.
That's because you know MySQL, so of course something that works differently is going to be more work for you to figure out.
I've used PostgreSQL for years, when I had to set up a MySQL database for some php app it took much more than 15 minutes to figure it out and get it running. The primary problem was MySQL's obtuse user management system.
With PostgreSQL I know that it's secure by default -- the default user has no password, so even if you enable password authentication it won't work (because it has no password!). You log in locally with trusted authentication, and issue the very logical CREATE USER. Edit the self-documented config file to allow remote hosts to access the database using your preferred authenticaion method, and you're done.
With MySQL, new users are automagically created by the GRANT command?! Huh? On top of that, passwords are apparently specific to a certain host string. Bizarre. Do I need to use localhost for the actual machine name for local users? What about remote machine without a reverse DNS entry? What's the order of precedence for '%' vs a more specific name?
Oh, the default 'root' account has no password ...and allows access over the network. Wonderful. Okay, so to change that do I use root@% or root@computer? How do I know I changed the right one and there isn't still some root@something entry? SHOW TABLES is easy enough, how about SHOW USERS? Nope, that's not it.
Time to check the startup guides. Well, one just has a single password change, another has 3 or 4 lines of 'delete from user...'. The reference for GRANT just has a bunch of caveats and warnings, and the "User Account Management" section goes on and on and somehow doesn't manage to tell me what I want to know.
To this day I'm not 100% sure if the MySQL install is secure. I decided my time would be better spent eliminating the MySQL-isms from the app in question so that it can run on Postgres like everything else on the server. There are some very strange queries in there - a lot of GROUP BY expressions that make no sense and aren't valid SQL. Some of it I'm not sure how it ever worked.
Parent
Re:Wow (Score:5, Interesting)
I think his argument is more marketing/PR driven. His main point is valid, in that MySQL claims simplicity/lightness when they don't have the features, and claims maturity when they add them.
Parent
news flash (Score:5, Insightful)
Just about every major non-open source project that has shipped with major bugs, the /. crowd jumps on for releasing poor quality products due to bad planning, poor communication, legal reasons, marketing deadlines, oh and the list goes on. When an open source project is shipped with major bugs though, what do I hear? Excuses. Is it just possible that people who develop open source are human, and make the same decisions, for the same reasons, as their closed-source counterparts? Which might lead to the conclusion that different methods don't necessarily yield different results; ie, that open source innately presents no inherent technical advantage over closed source, only social and legal advantages. Uh oh... they're getting a duck and a large scale out. I think that's my cue to post and run now...
Re:news flash (Score:5, Interesting)
Oh, I agree, every product that's ever shipped has shipped with bugs.
But you gotta put this all in perspective, some glib talk about how everyone is equal in the eyes of bugs just doesn't apply here.
First off, the context. We're talking about a database, your warehouse for your most valuable asset. This is not a place where you want to encounter mistakes, and caution is the word. You might hear excuses for some, but those people are idiots. This is /inexcusable/.
If you read the article, the things he says basically boil down to "this product is as stable as a house of cards and if you use it, treat it with all the care and caution you'd give a newborn child." I'd love to pick an excerpt from the article and copy it here, but it's just TOO RICH. Every single thing this "Monty" says would make your average MySQL apologist cringe, and makes normal people and DBAs stomachs turn.
Honestly, I think I'm gunna be sick. I don't care if MySQL is a good product or a bad product as such, I only use it for stupid things that do not matter at home, like my MythTV, never ever on anything that could be called "production." But having read this article and gotten a picture of what is, evidently, the thoughts of the minds supporting the creation and use of MySQL, it makes me ill. These people should just come out and say "there's no explanation we can give, this is crapware and we're really sorry if you got hosed by it. Don't use it at all if you aren't already." Instead this guy bends over backwards to explain how this broken database is actually quite useable, and ready for "general production" - how that's different from just "production" is clear: apparently "general production" refers to systems with zero value (less than my MythTV box, which will NOT be getting an update to this version).
Parent
Re:news flash (Score:5, Funny)
Cognitive dissonance is a wonderful thing.
No, it's a terrible thing.
But I want it. Badly.
Parent
MySQL x.1 releases gives me the creeps (Score:3, Funny)
PostgreSQL has the same issues (Score:5, Interesting)
It just has them on a different scale and there's a different release. If you look through the past release notes for pgsql, you'll see that occasionally one release would come out with some horrific server crashing bug, get reported and get fixed.
Now, the timeframe is what is the key. For MySQL there are server crashing bugs that have been in place since 2003 or before.
For PostgreSQL, once such a bug is documented and reproduce-able, it is generally squashed in hours, days, and occasionally, for really complex problems, in a week or so.
Re: (Score:3, Insightful)
Re:too much adoration of personal database favorit (Score:4, Insightful)
Instead of cursing every product with which a writer has had bad experiences, the key to reducing grief is to remain aware of the likely risks and rewards of each approach.
We can be as relativistic as we want, as though every system is a snowflake with it's own beauty, but in the real world, sometimes value judgments are useful.
For instance, if you design a truck and I design a car, we can both respect each others' designs, and differ on opinion. You might prefer towing capacity, and market that benefit to construction workers and farmers. I might market the fuel economy and handling to commuters.
If someone designs a car that sometimes explodes when it rains and the steering wheel in the trunk, it's a bad design, period.
Parent