Tip of the Day — What MySQL Version to Use
If you are running MySQL on Windows this really doesn’t concern you. However, especially for Linux, this is a relevant discussion.
I guess this will be subject to much debate. However, in my mind, it is clear. I have for a long time used the compiled binary versions of MySQL (that MySQL AB provides) rather than .rpm files (on RedHat) or .deb files (on Debian). Why? Simply because I am not tied down to a vendor’s idea of what version of MySQL I should be using. I determine what version of MySQL we run in house. And I promise you that my servers run a OS that includes an older package of MySQL than I am currently running in production. I just checked. It is quite a bit older. Now, mind you, I have absolutely nothing against the operating system itself. It is a fine operating system. Using the compiled binaries of MySQL gives me control over what goes on and as a DBA I like that.
I suppose there is a downside to this. The vendor could fix a security problem before MySQL makes a fix available. Unlikely but theoretically possible.
10 Comments so far
Leave a reply
In Debian it’s not just theoretically possible that a security problem is fixed before MySQL releases a new version, it’s the common practise.
See I knew this would generate some fun! I didn’t say this is in the post .. but we use Debian Etch on our servers. They generally are good about security patches. However, they are also packaging 5.0.32.
No thanks!!
Exactly for this reason (not only with mysql) we started to look into gentoo. After about a year of painful testing and tweaking we are close to deploying it in production to replace redhat on some 10 boxes…
I think that generally, security patches are not the issue for production servers, since they have no direct external exposure. Fixes for functional problems are much more relevant as they direct affect the application. You’d want to make sure your replication is as stable as possible, even if you have not yet been bitten by a problem that others have reported.
Right now, a key issue lies with the fact that community builds by Sun-MySQL are only periodic whereas if you want the latest patches you need to subscribe to MySQL Enterprise or gets the enterprise builds from elsewhere. Is “speed of patches for production use” something that should be charged, or should bugfixes be available quickly to all who use the software? An interesting debate.
While you can make a valid case for the former, I think I lean towards the latter. It’s not just about providing extra value, it’s about the perceived quality of the product and for that the community is vital. Putting the quality behind a pricetag makes it problematic. That’s not added value, but pricing something that the community feels should be theirs anyway.
Not that the community is always right in what it feels it should be able to get, but in this case I reckon they may have a point.
Arjen,
Very insightful about security patches. While I had no crystal-clear thought of this somewhere in the murky depths this is what I was thinking. And I know the debate is going back and forth within MySQL about the Community vs Enterprise and patches and so forth. I weigh very heavily on the side that we on the Community side of things should have access to the code if not before Enterprise certainly at the same time. If for no other reason than the the MANY more Community users will help to uncover problems and get them fixed quicker. I really think that the Enterprise license should buy you two things:
* direct access to the MySQL Engineers with bugs
* more functionality possibly ????? I am actually very uncomfortable with this, but at least in the case of MySQL Workbench it seems to be working well
* NOT different codebases
I could be wrong about this. Been before…will be again!! I just think it is interesting how MySQL employees have publicly said that they don’t agree with the current setup.
I think for say 95% of users the version which is shipped with operating system is good enough. It works so you might not want touch it.
I tend to make people to upgrade when there are reasons - something does not working well or some features or performance improvements in new versions are desired.
Note especially with RPM based distributions there is the chance you will break something by installing versions from mysql.com - they are quite commonly not built the same way and have different package naming.
Just for the record… The Debian MySQL maintainers provide an up-to-date version of MySQL from Debian testing (currently 5.0.51a) for stable on http://backports.org/ as well. You don’t need to stick with 5.0.32 when running etch.
[…] Murphy’s Diamond Notes has a tip on what MySQL version to use if you’re running Linux. The tip and its comments sheds some light on different distributions, package managers, and […]
the problem with vendor packaging is that often the version numbers do not correlate with MySQL versions, and vendors don’t bother to change the version # of the original version they patched. So it might say 5.1.22 Debian but you have no idea what’s in there — you have to look at the manual for the change notes in 5.1.22 and then whatever changenotes Debian may or may not have.
Sheeri, of course the MySQL version number in Debian correlates with MySQL versions. It’s a MySQL version x and some (important) patches, e.g. the official patch from 5.0.52 for MySQL bug #30666, which is fixed 5.0.51a-1 from Debian, but not in the latest community release of MySQL.