This is another case of a developer, a brilliant one, mind you, one of the brightest in the open source arena, but a developer nonetheless, who has a non-user oriented mindset and is inflicting his view on the users.
I will stay clear of the reasons. Why the co-founder of MySQL decides to spoil the party on release day and ambushes his colleagues with a truckload of blame is beyond my understanding.
What concerns me is the patronizing plea that Monty uses against the users. "Don't use MySQL 5.1"? Really? What about the ones who have already been using it for months, if not years? Don't they count for anything? Has he ever used it?
I look around, and I find plenty of stories from people who have been using MySQL 5.1 in production for long time, starting from the people at MySQL.com itself. And then there are the ones of the Use Case competition, who have shown that 5.1 in production is not anathema. And then there is me. I haven't participated to the competition, but I have been using MySQL 5.1 with partitions for 8 months already, and it suits my needs perfectly.
I don't know of the other features, but for partitioning I have something to say. Let's look at Monty's claims:
Partitioning in MySQL 5.1 should be regarded as a step to a full partitioning feature with parallel query. Parallel query is however not scheduled even for MySQL 6.0.Why should I care? Yes, parallel queries would help, but with partitioning I got performance gains from 10x to 100x, and I couldn't care less if the feature is not as perfect as it would satisfy a stellar developer.
For now partitioning is mainly useful in the case where you need to frequently drop a well defined part of a table (like one month of data) and when MERGE tables are too cumbersome to use.I strongly disagree. MERGE tables were a crude hack that I used as long as there was nothing better. Partitions solve my problems nice and square. My insertion and retrieval speed increased, and that's all I need.
If one partitioned table crashes it's very hard (sometimes impossible to repair it.Probably Monty wasn't paying attention when Bug#20129 was fixed.
If you get a server crash during ALTER TABLE of a partitioned table you may loose all your data for that table.I would like to see proof of this.
Partitioning is very slow and can become unusable if you have a large number of partitions. This happens even if you only use a few of the underlying tables in your query.
My experience tells me otherwise.
So, it looks like Monty has never used partitioning, probably because he doesn't think that the implementation is good enough. Is this a good reason to scare away everyone else? I think not.
11 comments:
And developers get to complain about users who haven't read the docs. For what fraction of users will online backup work? It is only done for MyISAM and Falcon engines, it does not do the mysql database and it doesn't backup temp tables. If you need 'online' operations, then you should not be using MyISAM.
But I am a developer and a user so I get to complain about myself all of the time.
Monty's post was harsh but not an ambush. The statements he made are well known among MySQL developers.
Monty never said that you should not use 5.1. He described it as a better 5.0 than 5.0. His concern is about features new in 5.1.
Uh, Mark, on-line backup and Falcon aren't scheduled (sic) until 6.0. Mr. Callaghan, really, take your own medicine and RTFM.
Yes , we should all listen to some DBA from nowhere about MySQL instead of the guy who wrote the thing! Not.
And since he's talking about bugs I think a developers point of view is somewhat more relavent than a users don't you sweetie?
@Boltar,
it seems that the whole point of the issue is that the guy did not write the thing. Not version 5.1.
He was busy doing other things while MySQL 5.1 was allegedly being mishandled, or else he would have fixed the bugs he is complaining about.
I tend to agree with your take on it Amelia: many people are using MySQL 5.1 to their benefit - now is as good as ever to release it.
Personally I am willing to take the factual content in Monty's post for granted. Sure - "There will be bugs".
But, like you, I too feel that his account of things seems quite a food deal worse than it really is.
Yet, at the same time I appreciate his in-depth opinion.
kind regards,
Roland
@Boltar -- calling Amelia "sweetie" is condescending. What would you have said if "Fake Amelia" was "Fake Mike"?
That being said -- Monty's points may be said in a harsh tone, but they're all true.
Hell, they're true for almost ANY software release, including previous upgrades of MySQL -- the first GA of 4.0, 4.1 and 5.0:
1) test before putting into production. (you'd better do this even if Monty said you don't need to!!!)
2) new features aren't robust yet.
3) there are still critical bugs.
How is *any* of this news? none of this is surprising, it all made me just yawn. Sure, Monty's tone is harsh, but we're all feeling pretty sore -- we were first promised a GA release in April 2007, so we've been waiting over 20 months for this.
But Boltar, *honey*, even a "DBA from nowhere" is entitled to her opinion. You're entitled to disagree, but using a condescending remark because she's a woman is outright misogyny.
Bolar, *dear*, you're entitled to be opionated (just like Amelia is), but please don't be opionated and misogynistic. It doesn't look good on you, *darling*.
As a response to Mark Callaghan's comment, this is the current state of Backup in MySQL 6.0:
- Backup works for all engines.
- Backup supports online DML operations for MyISAM, Falcon, and InnoDB.
- The backup includes every object belonging to the databases that are being backed up, such as triggers, views, procedures, etc.
- Backup does not include temporary tables. We had an internal architectural review some time ago and it was concluded that we should not backup temporary tables. Perhaps this was the wrong decision. If more people think this is wrong, then we will reconsider if we should add them to the backup. I've opened a bug report. Great if people can put comments in this (and add use cases), if they see this as a big drawback, so that we can prioritize the work correctly: http://bugs.mysql.com/bug.php?id=41171
It is true that there are limitations to MySQL 6.0 backup that will be lifted in later versions, e.g. is not "online" for DDL and it is not yet backing up every object of the MySQL Server.
To avoid having to wait too long for the next version, we try to balance feature scope with stability work, so that it is both useful, stable and delivered on time. As you can imagine, this is quite a challenge. :) It is great with the community feedback on this to make us prioritize the work in the right way. So far, we have closed more than 175 bugs in backup and there are much more tests to write and bugs to fix before backup is GA-ready. Please continue to help us test it and report bugs on any problem you find.
@Lars - Does online backup work for InnoDB by doing the equivalent of select statements and restore by doing the equivalent of insert statements. If that is the case, how many InnoDB users will use it?
@Mark - Yes, currently InnoDB and Falcon are both backed up using the consistent snapshot driver since there are not yet any native drivers for these engines. The introduced backup driver interface makes it quite easy to add such drivers as part of the engine plugins in the future.
Fake Amelia does likewise, viewing the controversy as, “Yet Another Case Of Developers vs Users”. -- Log Buffer #126
Post a Comment