Quality of 5.1 GA release
With all due respect to Monty (and I mean that � much respect is due), I have some serious issues with his portrayal of the 5.1 release. I hate to make my first entry on Planet MySQL about a controversy, but he encouraged people to blog about their experience with 5.1, so that�s what I�ll do here.
Overall Quality
As a long time user, I am very confident that the quality of 5.1 GA far exceeds that of the initial 5.0 GA release (5.0.15). In fact, I would go further and suggest that the MySQL organization has if anything been too conservative about declaring 5.1 GA.
It�s obviously true that there are still many bugs open. However no software is bug free, especially not those with codebase as large as MySQL. So the question is not if they are bug free, but are the outstanding bugs serious enough to prevent a release label. The benefit of a public bugtracker is that we users can see what is outstanding and how it may affect us, however Monty has abused this openness to compile a sensationalist list which overinflates the seriousness of the open issues.
Of the bugs Monty referenced, the most serious are those with Row Based Replication. I will agree with him and suggest that is not production ready � however to be fair this feature not even enabled by default in 5.1.30. Of the rest of the bug list, they appear to me to be largely edge cases which crop up when mixing lesser-used features. One could easily compile such a list of any large and complex open source project.
My Experience
I have been developing for and administering MySQL 5.1 production instances for 18 months, and this has been my experience. We chose MySQL 5.1 in May 2007 for our download logging database for the partitioning feature, since the application largely does updates/selects based on the partitioned Primary Key this has given us superior performance. Since that time we have not seen *any* table corruption or random server crashes relating to mysqld, despite having tables with hundreds of million of rows.
In Nov 2007 I set up an aggregated reporting database using 5.1, this has approx 150Gb of storage across 200+ tables. This uses 5.1 features such as partitioned tables of several different types, and MySQL events. This database handles very complex analytical oriented SQL including lots of �fancy� tricks. Again, no table corruption, no random server crashes. By partitioning tables along date ranges, well formed queries can perform much faster if they can be constrained to only examine certain partitions.
In Aug 2008 I upgraded a separate database from 5.0 to 5.1. This database is fairly large (300Gb) and uses a variety of complex OLTP operations, but does not (yet) use any specific 5.1 features. Again, this has been very stable, we saw minor one bug relating to truncate/auto_increment which was fixed before GA release. No corruption (except on disk failure on a slave), no server crashes except for a Linux kernel bug unrelated to mysqld.
Not once in any of these three scenarios have I seen any issues with data integrity, corruption, or any of the bugs listed in Monty�s blog post. This is true despite several power events at our primary data centre causing servers to suddenly power off.
Partitioning Usefulness
�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. 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.�
This is misleading at best. First of all, MERGE tables are MyISAM only, which immediately vetoes their usefulness for people who care about their data integrity. Maybe that will change when Maria is finished, but serious users have only InnoDB to consider in the mainline release.
For these users (myself included), partitioning is an extremely useful feature as outlined in my experience above. When doing operations based on a partitioned key on tables with hundreds of millions of rows, the limited MySQL implementation of partition is essential for performance.
Release Model
�We have changed the release model so that instead of focusing on quality and features our release is now defined by timeliness and features. Quality is not regarded to be that important. To quote Mårten Mickos: �MySQL 5.1 will be release as GA in or before December because I say so�. Mårten�s reasons for this is that he needs something he can sell and a release marked �GA� is much easier to sell than a release marked �RC�.�
One thing I believe everyone can agree on is that the release model used for 5.0 and 5.1 is clearly broken. When it takes three years between releases, this discourages community contributions to the mainline tree and has encouraged forks to develop instead such as the OurDelta fork. I think a release model of more smaller, more rapid changes would be a welcome change to the MySQL release process.
And yes, this means drawing a line in the sand and saying that despite bugs this version is considered release quality. If you are too lenient you have reputation breaking releases like 5.0, and if you are too stringent you have immense delays like with 5.1 which also hurt reputation.
The model of proprietary software releases (defining a featureset and not releasing until an arbitrary quality barrier is reached) clearly hasn�t worked for MySQL. However a time-based release process has been very successful for various open source projects, especially larger ones like the Ubuntu and Fedora distributions. Sometimes features don�t make the cut (like Federated Engine didn�t in 5.1 GA) but that is OK and you wait until the next release.
As a MySQL user I would certainly prefer to know that a release is coming by an approximate date, even if that means certain features I want are not going to be included because of quality concerns. That way at least some forward progress is made and features are going to be better tested since many users will wait until GA versions to start testing.
Conclusion
Obviously 5.1 is not a perfect release. Quality is critically important to a database and I hope MySQL/Sun takes note of Monty�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.
Tags: 5.0 , 5.1 , bugs , GA , monty , partitioning , RBR , release model
November 30th, 2008 at 6:07 pm
Ryan - of course your personal experience is valuable on its own and as one case, but I don�t think there�s any foundation for extrapolating your experience onto the overall 5.1 quality or suitability in other operational environments - and that�s the case both in the positive as well as in the negative.
It�s a pity your post went in that direction, as I think it would�ve otherwise been more valuable. Thanks anyway.
November 30th, 2008 at 6:51 pm
Arjen: I spoke of my own experience and my own opinion based on that experience � that was specifically my intent. It should be considered one data point, and Monty requested others to share their experiences so perhaps we will see other data points as well.
Regardless, based on the usage I have seen in my shop and also based on conversations with other users who have deployments of 5.1 for non-trivial applications, I do not believe that a �sky is falling� attitude is warranted.
December 1st, 2008 at 7:54 am
Ryan:
I fail to see a �sky is falling� attitude in Monty�s post. I do see that he�s nitpicking at some things that are well known � for example �don�t use 5.1 in production without a few weeks of testing.� That�s a no-brainer, with any upgrade!
His tone is negative, but his comments are spot-on � he even says if you�re new to MySQL you should start with 5.1.
I think your post is just agreeing with Monty � that 5.1 is good, but you shouldn�t blindly upgrade � that is, agreeing in facts, but not in tone.
December 1st, 2008 at 9:24 am
Among other comments, Monty stated that 5.1 is a better 5.0 than 5.0.
December 1st, 2008 at 9:52 am
Ryan, thanks for your feedback. We are certainly planning to change the release model to enable more rapid releases. That said, I think it�s a common misconception that much of the 5.1 delay is because we were waiting for certain features to be completed. It�s more because we�ve fixed 1000s of bugs in both 5.0 and 5.1.
Also, now that 5.1GA is out, I want to do a 5.1 �reflection� to gather feedback from our engineers, but also the Community, on what we could improve. I would welcome your (and others) participation in that.
Jeffrey
December 1st, 2008 at 3:39 pm
Ryan - I agree, 5.1 is a solid release, at least in terms of how I have used it. I started building data warehouse solutions with 5.1 about a year ago because I needed table partitioning for very large fact tables. I have not experienced any crashing or corruption problems, and performance has been very good.
I believe it is unrealistic to expect that highly complex software will be released without known and unknown anomalies. This has been my experience as both a PeopleSoft and an Oracle employee. Holding off on GA until �all bugs are fixed� is the equivalent of polishing an apple until it rots.
Chris