Is MySQL 5.1 really a better 5.0?
With all the furor over MySQL 5.1 GA, its release schedule, its quality, etc etc I think a fundamental claim is being left un-examined. Lots of people are saying that if you leave out the new features in 5.1 and look only at the features that existed in 5.0, it’s better quality.
The implication is that the process of building 5.1 looked like this: rip out nasty code and fix it all up, so there’s a brand new architecture free of code debt. Adjust existing features to use this new, high-quality, sensible server architecture. Add new features.
Is this accurate?
Time will tell, and I have not yet seen enough of 5.1 in real-world production environments. As Peter says, it’s not how many bugs there are — it’s how many bugs affect you. In my line of work, we see bugs that only show up if you’re, for example, running a server with hundreds of thousands of tables. Or similar edge cases. I see a lot of routine things, too, but my point is that I am somewhat reserving my opinion about 5.1’s quality of existing features. As an example of what I mean, there were some bugs with 5.1 not using indexes correctly — a serious regression from 5.0. These have been fixed. Will there be others that haven’t been found yet? Probably.
Here is my gut feeling about a few existing features: triggers were always a hack and remain a hack. The memory allocation algorithms of the query cache are suboptimal, and that hasn’t changed fundamentally. Geospatial functions are largely unusable, and that hasn’t improved. The silly behavior of correlated subqueries has probably been MySQL’s number one slap-me-in-the-forehead misfeature since it was introduced in 4.x, and that isn’t fixed (it will be in 6.0, but that’s a whole other topic). Failsafe replication is code rot that was partially implemented and then abandoned in 4.x, causes bugs, and they haven’t even removed the code (read the bug report!). UNION still uses a temporary table, whether it’s required or not. LOAD DATA FROM MASTER never worked to begin with, and it’s still there — it causes problems and should be ripped out. The Federated engine is probably best left alone. Group commit is still broken for InnoDB when binary logging and XA transactions are enabled. (This was broken during 5.0’s release, is a serious regression since 4.1, and is definitely a server architecture problem. So much for the beautiful new server architecture in 5.1?)
Don’t get me wrong. I’m not trying to bash 5.1’s quality. I’m just taking issue with this unchallenged assertion that everything that wasn’t introduced in 5.1 is rock solid, performs better, and works beautifully now. I don’t know for sure; I suspect it is partially true and partially false, but time will tell.
I will say this: I’m generally happier with the quality and stability of 5.0 in the last little while, say since 5.0.6x. If you don’t need 5.1’s new features, why break something that works?
> This was broken during 5.0’s release, is a serious regression since 4.1, and
> is definitely a server architecture problem.
if you read the comments in the bugreport beyond the very first one, you’ll
see, for example, “No changes needed in MySQL, Heikki says. When he gets
around to it, he’ll find out for sure–it’s a resource issue.”.
Or ” [11 Sep 2007 16:01] Heikki Tuuri: Changing severity to Feature Request”.
So much for the server architecture problem ?
Sergei Golubchik
11 Dec 08 at 9:41 am
I stand corrected. Actually, if/when someone fixes the bug, the truth shall be known :-)
Xaprb
11 Dec 08 at 11:18 am
The pointless code for failsafe caused downtime for me in production. Sadly, the fix for it was partial — http://bugs.mysql.com/bug.php?id=21132. If you read the code it looks like there are still errors that will prevent the slave IO thread from reconnecting as expected — http://bugs.mysql.com/bug.php?id=41400. And this is a huge problem when you run replication over a flaky network.
Mark Callaghan
11 Dec 08 at 11:58 am
I couldn’t agree more. From all of the work we’ve been doing to upgrade servers to 5.0.68 and make that our standard install for new servers, it would be silly to introduce 5.1 into the mix when just about every single client we have does not need the new features (yet), and we already have a very stable .68 release to work with.
I’m all for progress but not at the expense of rushing releases.
themattreid
11 Dec 08 at 11:37 pm
[...] reading Baron’s take on 5.1, I saw Mark’s comment and part of it stuck with [...]
The probability of failure is 1. | Ramblings
11 Dec 08 at 11:46 pm
Repent, ye foul-mouthed sinner! Monty has spoken: “verily,” said he, “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″.
This shall be all the proof thou shall need!
Seriously, you make a good point. What a lot of people seem to have missed in Montys post is the “if you are a new user” bit.
Carsten
12 Dec 08 at 3:31 am
Log Buffer #127: a Carnival of the Vanities for DBAs…
Well, it’s been a long time (100 editions in fact!) since I have hosted a log buffer, but I thought what better way to break-in the new blog than by hosting the 127th edition of Log Buffer. Let’s get started!
The big story in MySQL this week was t…
zillablog
12 Dec 08 at 12:48 pm
Sergei, please see http://www.percona.com/docs/wiki/percona-xtradb:specs:fix_broken_group_commit and see what you think about Yasufumi’s analysis of group commit.
Xaprb
18 Jan 09 at 9:14 pm
I don’t think the reason for the mutex is correctly explained there. Same order or not, still either a transaction can be committed both in innodb and binlog or in neither. XA guarantees 100% exact recovery without any additional mutexes on the storage engine side. And you don’t really care about the order of transactions in the innodb redo log.
What cares about it, though, is innodb hotbackup – because it, precisely, reads the innodb log. And it needs to know the corresponding binlog position. It’ll break if innodb log positions and binlog positions won’t be in the same order.
So, as far as I understand – and I can be wrong, caveat emptor – this ordering is only needed for innodb hotbackup, and not needed for a normal usage.
Sergei Golubchik
19 Jan 09 at 6:02 am
Thanks Sergei. I’ll make sure to pass your thoughts on to Yasufumi.
Xaprb
19 Jan 09 at 9:42 am
Sergei,
I think innodb hotbackup is one of important reason for them too.
But I also think,
though binlog is implemented as storage engine, it is not transactional storage engine (binlog don’t arbitrate any conflicts of the each operations) and only using XA interface of the storage engine plugin. It may be not XA problem, using the plugin XA interface to keep order of logs only.
Of course, the exactness of the order will depend on isolation level of transaction and binlog_format. The level “SERIALIZABLE” or the format “ROW” may keep the order exactly (or may not need the order).
Yasufumi Kinoshita
19 Jan 09 at 8:36 pm
Right, binlog is not a transactional storage engine. But why would it matter ?
Why one may need commits in binlog and innodb log to be in the same order (besides hotbackup) ?
Sergei Golubchik
20 Jan 09 at 6:59 am
Well 5.1 for production is a no-go for me. I had problems importing data with mysqldump, problems starting the server, binlog problems…
As Carsten said.. if you are a new user and need it for some school project it may even work but for production use I will stick with 5.0.67
Can’t even figure out why 5.0 was stable enough from the first releases and 5.1 isn’t at 5.1.32…
Sorin Pop
31 Mar 09 at 4:11 pm
Most people think that 5.0 wasn’t stable until 5.0.3X so 5.1 might be stable earlier than 5.0 was depending on the features you use.
Mark Callaghan
31 Mar 09 at 6:34 pm