October 24, 2014

Which Linux distribution for a MySQL database server? A specific point of view.

One of the more common questions I get asked is which Linux distribution I would use for a MySQL database server. Bearing the responsibility for someone else’s success means I should advise something that is stable, reliable, easy to manage and has plenty of resources available online. It should also allow running MySQL without too much hassle. Unless there are individual circumstances, it actually makes the decision quite easy.

There are probably only a few distributions, which can be considered: CentOS, Debian, RedHat Enterprise Linux, SuSE Linux and Ubuntu. Of course CentOS and Ubuntu derive from RedHat and Debian respectively, but their install bases are large enough to mention them separately. Running MySQL won’t be much different whether one or another distribution is used. All use common Linux kernel – the heart of Linux operating system – which in principle will behave the same way in all cases. The kernel versions may be different in different distributions as for example RedHat is very conservative in that area for the sake of compatibility with drivers and applications throughout a release lifetime, which can be even several years. Newer kernel versions may carry new features or slight performance improvements, however these days it is rarely important to MySQL users. If it is to you, then you probably did your own research and benchmarks already and this post is not for you.

For most people, managing a database server during its lifetime comes down to this rather boring process – install, configure, tune, start/stop MYSQL, upgrade MySQL, 10x start/stop MySQL, upgrade MySQL, downgrade MySQL, upgrade MySQL, install a security fix for something, 20x start/stop MySQL, upgrade MySQL, … . Restarting and changing MySQL version might just be the most critical operations you ever do once server is moved into production. Success and efficiency of these operations may directly impact service availability, which means that what you could wish for the most are quick and problem free restarts and upgrades (or downgrades).

From my experience, and I have done thousands upgrades and downgrades in my life, the least number of problems come from RPM packages available in RedHat, CentOS and SuSE. In fact, I cannot recall encountering any serious problem with that package management system. Moreover, I have not seen broken systems, where installing or updating a RPM package would be impossible without resolving tons of problems first. It can obviously mean that RPM has flaws and does not verify consistency very carefully, but it never turned out to be any problem.

On the other end there are Debian and Ubuntu. Both use tool called dpkg for package management. There isn’t a month that I log in to a system based on either distribution where there are no issues with packages consistency. Unfinished installations, unresolved conflicts are so common that it’s just beyond simple negligence. The packaging system is just not robust enough. Another problem is that one broken package may block you from installing or uninstalling anything else. Imagine that someone left system in such shape, you prepared for downtime, stopped MySQL and… error – text editor has not been properly installed, so you cannot upgrade MySQL either until the problem is fixed. In a stressful situation when downtime clock ticks – annoying at best. Resolving problems can easily lead to unexpected consequences. Here’s a different scenario:

# apt-get install binutils
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.

While everyone should stop and check what this means instead of following the advice blindly, many still would just do as they were instructed. In this particular case the problems were with MySQL packages upgraded from 5.1 to 5.5. The former were not fully uninstalled, the latter were in half-configured state. Obviously binutils has nothing to do with MySQL, but it would not install anyway. The larger problem – chances are that fixing this with ‘dpkg –configure -a’ would cause MySQL to shut down. The MySQL package scripts for Debian force MySQL stop/start upon completion and unlike RPM, dpkg does not have any opt-out option.

More problems can come from the standard Debian init (startup) script for MySQL. By default it not only starts database, but also updates system tables (if needed), scans all tables for consistency problems, etc. I mean, that works great for a computer at home or a tiny and unimportant system, but any of these operations may have severe consequences on a large production system. This is why all of this extra functionality was stripped from Percona Server. This behavior actually appears to be a general problem with Debian – it wants to be smarter than you. This might work for desktops, but anywhere else it is plain stupid and makes you waste time on outsmarting a wise-ass system. Of course I do know some people who like such approach, but he is Belgian and they were unable to form a government for 541 days… (congrats that you finally made it this week, btw! :))

The init scripts for RedHat, CentOS and SuSE are simple and do only what’s required of them – stop or start MySQL. No problems there.

It’s now clear that I never recommend Debian or Ubuntu, because I do not like some of the “mechanics” and I feel people are generally safer if they do not use any of these two. With the choice left between RedHat/CentOS and SuSE, I lean towards the former. Why? RedHat and CentOS are the only platforms getting packages from all MySQL and MySQL-fork vendors – Oracle, MariaDB and Percona. By my observations RedHat and CentOS are also much more frequently used with MySQL, so there will be more resources available online.

But if you are a skilled systems administrator or your company hires one, then you could use pretty much anything, including my favorites such as Slackware and Gentoo.

In the beginning I mentioned that individual circumstances may influence the decision. One example of such specific case, which limits your options, is for example a requirement for commercial support for the operating system. You will have to choose between RedHat or SuSE. Another such case can be related to hardware. Any newly released component may simply lack support from the Linux kernel, but this can also be the case for any high-end/enterprise class equipment. Hardware vendors may release Linux drivers on their own, but often only for very specific Linux distributions.

About Maciej Dobrzanski

Maciek is a former Percona employee.
An IT consultant with the primary focus on systems, databases and application stacks performance and scalability. Expert on open source technologies such as Linux, BSD, Apache, nginx, MySQL, and many more. Co-author of dba square - a blog about how to manage, scale, and optimize MySQL performance!

Comments

  1. Brian Boatright says:

    Thanks for this article and advice. I am just getting started moving from running our Classic ASP app on IIS6 using MySQL to PHP and MySQL. All so I can use Percona Server and the benefits it provides like XtraBackup. So my focus is protecting the MySQL Data not ease of PHP install or use. Most of the articles I’ve read on PHP suggest getting started with Ubuntu. This article gives me a good start and avoid headaches. Thanks!

  2. Interesting article.
    BTW, what do you think about this bug with upgrade package:
    https://bugs.launchpad.net/percona-server/+bug/557270

  3. As a long time Debian person, I can whole heartedly say: This is sound advice!

    For those looking to run a MySQL server purely from packages:

    I can say that MySQL support in Debian has been exceptionally poor/slow, and the ABI problems with MySQL and Debian has definitely not helped.

    For people looking to start a quick development environment, or run something low-key, I can’t say I oppose using the MySQL packages on Debian (However, you will feel the burn when the packaging is sluggish to upgrade and you can’t toy with the improvements)

    For anything production or serious on Debian- you’d better get comfortable with compiling it manually to stay abreast.
    Doing so has it’s own host of issues: The source provides insufficient startup scripts – have fun pulling your hair out with mysqld_multi – you’ll need to modify them.

    PS: Percona is a ray of light for sane, package based MySQL on Debian (They provide an apt repo) Thanks!

  4. LenZ says:

    Shameless plug: have you looked at Oracle Linux yet? The ISO images are freely available and distributable.

    If commercial support for the operating system is a requirement, it would be a very good match – support for both the OS and MySQL could be purchased from a single vendor and goes through the same interface (My Oracle Support).

    The Unbreakable Enterprise Kernel that is shipped with Oracle Linux also addresses the hardware-related requirement you listed – the UEK is based on mainline Linux and will be refreshed/updated every 12-18 months. The next kernel will be based on Linux 3.0 and is currently in beta test. So you can enjoy both the improvements, new drivers and features of a new kernel, while still keeping your stable OS platform (the kernel is available for both Oracle Linux 5 and 6).

  5. That’s interesting. My experience is just the opposite: apt-get always seems superior to rpm/yum in terms of managing dependencies, immediate resolution, great cleanup after uninstall…
    Heh, and it’s all lower-case letters! Sounds silly, but how many times I could not guess the capitalization method for an RPM package, then had to resolve to yum list available (takes ages) | grep (can’t use yum search for pretty much the same reason).
    I’ve had my share of RedHat/CentOS/Slackware/Debian/Ubuntu. Package management in RedHat has come a long way since the early dependency hell days (I still can’t look at rpmfind.net), but still not up to apt’s level.
    In terms of drivers and support I suppose RHEL are way on top.
    In terms of MySQL I never use packages anyway :) Always install source/binary.
    Most annoying thing about Debian/Ubuntu + MySQL is the automatic creation of /etc/mysql/my.cnf, which “nicely” overrides one’s own /etc/my.cnf config. I’ve spent long hours on this — again and again…

  6. Back in the mid 90s when I first started seriously monkeying around with servers, I tried many distributions (Woo Distrowatch!) – with the watermark at the time being Redhat and maybe SUSE or Mandrake due to their awesome installers. I had what was essentially a base Redhat install of an Alpha (processor) port brick two different systems via RPM conflicts (corrupted RPM db was the least of my issues) to the point of wiping the disk and trying a different OS.

    After a few weeks of trying to make things work with flavors of RPM (individual file dependencies for parts of libc and friends were the best!), I finally get to experience the joy of apt and dpkg. Even when people screw up their dependencies, I’ve always managed to recover by following the prompts, with a –force-* argument needing to be used in the worst cases. :)

    What really sealed the deal was ‘apt-get remove’ and Debian’s insistence on using the Filesystem Hierarchy Standard. They didn’t follow it perfectly, but as an aspiring systems admin, being able to sanely add/remove/configure/find programs on my arcane Linux system (It may be much better these days with things like yum, but the RPMs I remember were a massive headache from a consistency standpoint) was a big enough selling point for me to switch to Debian years ago, and luckily hasn’t managed to fall apart for me since then.

    I certainly do get annoyed at individual maintainers’ methods on packaging sometimes, but Percona has rescued me from the MySQL side of that issue. I will say that mixing in Percona’s libmysql libs and such with the main repositories without pinning (something I’ve had to do maybe 4 times in 9 years) has caused me a few nasty headaches with bringing in the wrong libs combined with getting upset about the mysql config directory (due to multiple packages maintaining it) – but after Percona retagged their debs most of that issue went away.

    Anyway, as someone who has found Debian’s packaging system to be a primary reason for using their operating system, I wanted to toss in my (perhaps garbled – I’ve been reading the mysql-master-ha wiki all afternoon) comments. :)

  7. @LenZ: I wanted to limit the number of distributions to mainstream to keep the post short, but indeed I could have mentioned Oracle Linux in the last paragraph – it just did not occur to me at that point.

    @Shlomi: So obviously there are pros and cons either way :)

  8. Mark Callaghan says:

    I enjoyed reading this. I use Ubuntu on my home servers because I find apt much easier to use than rpm tools. But I am not an expert sysadmin and the servers are far from production.

  9. Lars Johansson says:

    Thanks for an interesting article. I started using Linux/mysql 2000, I was at the time recommended MandrakeMandriva. I have never had a problem with that combination. I install/upgrade and then forgot about my server for a year or two. Now i built a new Intel 2011 server and planning to install Mandriva PWP 2011/ mysql5.5 (My server responds to 10 million queries a day). I am totally ignorant of other Linux distributions, should I stay with mandriva or go for another distro? I’m glad for any comments.

  10. Abe Hassan says:

    We generally avoid using package managers for managing mysqld specifically to avoid cases where the package manager does something dumb (leaves half-installed packages, restarts mysqld, etc). So we use tarballs straight from MySQL’s site. Given that … is there another major differentiator, other than package management, in your mind?

  11. Michael Lednev says:

    Slackware for MySQL? OMG, you must be joking, right?

  12. Schlomi’s and Mark’s comments remind me why I use (K)Ubuntu: RPM being inferior was mostly for the lack of something like apt-get. Now I use also CentOS for work and yum seems to work just fine. The packages not being lower case is another dark page in the history of MySQL-…rpm packages!

    On the other end the “helpful” things the Debian/Ubuntu MySQL package wants to do for you at startup is a well known weakness. I think this reflects my general feeling about these distributions too: Red Hat has focused completely on the server market, and it’s nice but others typically compete with desktop and ease of use features.

    Very good article.

  13. Moin Maciej,
    you forgot to mention debian used to have kill -9 in there init-script.
    /me still prefers debian over the rest.

  14. Lars: Mandrake 10 years ago had urpmi, with all of the benefits of apt-get. It stands out as a positive exception in the world of rpm based distros. Unfortunately they then had other QA, management and whatever problems. It seems Mandriva today is more or less dead, and I’m unsure of the Mageia community fork.

  15. Thanks for your article.

    As a Debian / Redhat admin for 12 years now, I prefer the dpkg system rather than rpm files. I think that apt is much more powerful than yum in external dependancy resolution, and tools like apt-cache, apt-file, aptitude are valuable tools.

    Regarding the issue about dpkg is sometimes blocking your whole system, it is just a safety condition to avoid breaking your dependancies. Most of the time, you have just to follow the instructions given by dpkg/apt in order to resume. I usually run first the download (apt-get install -dy [packages...] ) before lauching the real installs.

    Regarding specific mysql packages now: you’re right to mention that the debian init script for mysql can do some bad things automatically (system table upgrades, table checks, …). And I agree with you it’s probably useful only on home or small databases. BUT, this is only a helper. All you have to do is modify /etc/mysql/debian-start (add exit 0 at startup for example), to disable these “features”. And this is a config file, so it won’t be modified by any further upgrades / downgrades.

    Lastly, I recommend using Percona packages on Debian. They are 100% compatible with stable Debian system (both in dependancy matter and in way of doing), and are often up-to-date with MySQL roadmap. No need to compile / package from scratch (and packaging MySQL from scratch in Debian is not so easy).

  16. @Abe Hassan: There is usually little that differentiates distributions dedicated for servers one from another other than package management and init/configuration scripts. Unlike in the BSD world, here everything uses common kernels, common libraries, common software. The relevant difference can be in availability of hardware drivers and/or custom kernel patches, but in most cases it probably does not matter. There can be many more differences if you compare to distributions that were not designed to work on servers – kernel configuration and many default system settings for starters.

    @Michael Lednev: Slackware was my first Linux distribution starting in 1994. I was sticking to it for a short while until I decided Linux was useless at home and moved back to (MS-DOS and) Windows. But I kept using Slackware to run servers until Gentoo arrived many years later. So it’s more of a sentiment than anything else. :)

  17. This is a great thread, thanks Baron for raising the visibility on this.

    I used MySQL, Oracle, Postgres and few others almost exclusively on Redhat distributions for years, going back about 2002. I wouldn’t say I fit the DBA role until later on and that was when CentOS became the distro I reached for. Lately, I’ve been working with MySQL and Percona on Debian. At this point I have no particular preference, but I think that apt is better than yum, and I think that it is true – @Rémi, the Debian starter configs could be better for a production installation.

    Apart from the chore of setting up configs/op scripts for a deployment, which is not really specific to Debian, I’ve come across a bug or two running on Debian that concern me. One has to do with high IO machines hitting a “Soft Lockup” around 200 days of uptime, the other has to do with a large data dictionary. The latter bug may not have to do with Debian specifically and I have it mostly sorted out. Having to manage our uptime with restarts is fine (I guess…), but it does make me wonder if the behavior would occur on a Redhat descendant as well.

  18. The init scripts on all of the distributions, as well as the ones shipped by MySQL, are broken in various ways. It came up a lot in the research I did on causes of MySQL emergencies. What I would consider to be a good quality init script for MySQL simply isn’t available.

    Whenever I mention this, someone asks why I haven’t written a good one. I have not been paid to, and it should be obvious that it’s not easy, or it would have been done already. This is an area where Windows is clearly a light year ahead with the services framework, at least for most purposes (customization is a weak area, but very few people need that).

    Debian actually adds quite a lot of changes to MySQL, and many aren’t aware of that. One of my least favorite is the editline/readline substitution.

  19. Another bad nuance is the deb-sys-maint account; Extra gotcha for folks looking to setup replication.

    Here’s one of my favorite init script problems in the shipped scripts: http://bugs.mysql.com/bug.php?id=61291

    Not sure if this is fixed in latest – Don’t start it twice! ;)

  20. This is quite the reverse of my experience. I used to use RHEL, switched to Debian, then Ubuntu. The RH rpm repos were just miserable, nothing ever seemed to get fixed, and it was stuffed with ancient incompatible libs. Dag Wieers’ repos were generally better but overall I was plagued by version clashes, ancient libraries that broke newer packages. I tried CentOS but found that was as bad, and nowadays has apparently got considerably worse. Distrowatch suggests many are deserting CentOS in favour of Mint.
    Current deploys of RHEL suffer from extremely peculiar path definitions (essentially you have to specify absolute paths for everything by default), and I find it impossible to remember whether they put stuff in /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin /usr/libexec of whichever folder they decided to use that day. I also find that their init scripts are typically completely minimal (requiring work before they’re usable, which is possibly as bad as them doing too much), and config files tend to be straight from the source, with no consideration of whether they contain sensible defaults, so you generally can’t rely on anything actually working once it’s installed. You always get a sense of minimum effort in RH’s rpm packages. yum is about on a par with apt-get, but aptitude is leagues ahead for conflict resolution, especially in difficult situations like mixed-release repos.
    RH’s documentation is a complete shambles. Googling for anything usually swamps you in ancient pages from RH 7.3 and 9, and nothing is sensibly labelled or indexed. Ubuntu’s support pages are not brilliant, but the forums generally work brilliantly and they seem to manage versioning on their docs much more sanely. It’s nice that great Debian sites like debian-administration.org apply pretty much equally to Ubuntu.
    While there is much in the way of hardware support for RH, it feels like using Windows! Some driver installers and firmware updaters (Dell’s in particular) do some extremely unpleasant things, like do immediate reboots without warning or asking, and use spectaculrly admin-hostile things like shar archives for installing. It got to the point that it was easier and safer to use manufacturers utility binaries (e.g. LSI) and extract firmware images from windows installers because the official RH packages were simply too dangerous and unpredictable.
    One of my favourite things in Ubuntu is the release schedule, or more that they actually have one. You know exactly what will be in a release, when, and how long it will be supported for. Desktop Ubuntu is not of any interest to me, but the server versions are thankfully free of the Unity fracas.

    As far as MySQL goes, one major omission from RH is XFS (frequently cited on this very blog as the FS of choice for MySQL), and it’s a pain to install. At one point we had a RH support contract and they refused to honour it if we installed XFS, and refused to do it for us. I don’t know if that’s changed.

    One big reason I use Percona repos over stock ones (aside from the wonders of XtraDB!) is that consistent versions of MySQL are available across OS releases, which neither RH nor Debian can match.

  21. I’ve used MySQL on Debian/Ubuntu, CentOS/RHEL/OEL, Solaris and on Windows.

    On Windows:
    There is no OS version of MySQL. And the MySQL Installer makes installing and upgrading very easy. I’ve used this only as a testing platform, so I don’t know how Windows behaves for production MySQL. The drawbacks from using Windows are in the third party software. There is a XtraBackup version for windows, but it’ quite hard to get it to run. Running the commandline client from a cmd.exe is really not nice as resizing the window is not easy possible, the default fonts are ugly and the beloved pager option in mysql monitor isn’t supported on Windows. Running scripts in Perl or Python requires you to install software from ActiveState of some other Perl/Python vendor and is sometimes limited. (The 64-bit MySQL Python module is only available if you bought a support contract).

    On CentOS/RHEL/OEL:
    The system MySQL is easy to install. CentOS 5 ships with MySQL 5.0.77 which is really old. The 6.x releases ship with MySQL 5.1 which is also to old if you want to start something new.
    The MySQL 5.5 packages from Oracle are good, but a YUM repository is missing, which makes updating harder than it should be. The Percona Server packages are also really good are available in a repository. Other software like MySQL Workbench might require you to add the EPEL repository to your system. And at least for Oracle there doesn’t seem to be any puppet packages available.

    On Debian/Ubuntu:
    MySQL 5.5 landed in Debian expirimental, and the default MySQL version has been 5.1 for some time. And indeed /etc/mysql/my.cnf also drives me nuts (wikimedia uses an empty file in their puppet repo to solve it). And the MySQL package is indeed too smart. Good things are that many other tools like maatkit are available and there is no real need to add extra repositories (unless you want Percona Server). Recently there have been .deb packages available from dev.mysql.com/downloads but they seem to have disapeared again.
    And Ubuntu is the platform I use most. Canonical sells support for it, but I mostly had bad expiriences with that.

    And Solaris:
    I used custom made packages with custom SMF manifests. And Solaris 10 didn’t really support repositories so updating required also some custom updating mechanism.

    And using the system MySQL should only be used for small, simple applications. For a production system I would use the latest GA from MySQL, Percona Server or MariaDB. I use tarballs on Ubuntu with mysql-sandbox for development and also (but w/o sandbox) for production. Using tarballs makes it easy to switch version using a symlink.

  22. @Maciej: Like Marcus said, with RHEL using XFS is quite hard. What’s your take on that?

  23. @Daniël van Eeden: XFS is available and supported in RHEL 6, so no problem there anymore.

  24. @Maciej: XFS is only available is you buy the Scalable Filesystem Addon which will cost you about $200 per year for a very small server.

    http://www.theregister.co.uk/2010/11/12/redhat_rhel6_package_pricing/page2.html

  25. @Daniël van Eeden: RHEL is a commercial product, so in this case paying for something isn’t necessarily a disadvantage for those who either want or need that kind of solution. You can use CentOS if you do not want to pay.

  26. m.sucajtys says:

    XFS is available in RHEL/CenOS/OEL. It was added as experimental in 5.4 (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/5.4_Release_Notes/Filesystems.html)

  27. BSD says:

    What about FreeBSD ? You have the choice between all versions, compiling is simple as “make install” in ports…

  28. @BSD: The MySQL version from the ports tree is very recent and of good quality. I don’t know if FreeBSD is able to give the same performance as Linux. A few years ago the threading support in FreeBSD was much slower that the threading support in Linux.

  29. BSD says:

    @Daniël van Eeden: Threading issues with FreeBSD + MySQL are old story and since Linux and MySQL should be more or less at the same performance level. For all those taking ZFS route, there are couple of settings to be respected (zfs block size, avoid double caching in MySQL and ZFS). On UFS, just leave everything by default, and you’re done.

  30. Boris says:

    Excellent post. I had the same experience years back when i decided to switch to Ubuntu Server. The server start up was very slow and I can remember i changed the script thinking/swearing in the line of ‘ubuntu should be minding it’s own business and stop interfering with my applications’. What really did it was that ubuntu switched disks after every reboot. It meant you had to reboot several times until you got lucky and all the disks landed in their correct position.

    Before Ubuntu we used Fedora. At some time we thought that Fedora might not be perfect for production use but we did not had much issues with it (just be careful when the kernel is updated, it may not boot). After a month of pain with Ubuntu we switched to CentOS and that is running flawless for many years now.

  31. Simon Mudd says:

    A couple of thoughts from your post.

    1. System MySQL packages may be old.

    The system MySQL may be rather old. RHEL/CentOS packages have often been too far behind the “latest stable packages” for them to be usable. Luckily Oracle does provide newer packages which tend to be a plugin replacement for the system MySQL packages, so it’s not such an issue. However, anyone who is looking at RHEL/CentOS seriously to run MySQL may need to upgrade to these “external” rpms.

    2. You can only install a single version of MySQL at once.

    Package management is good but both the system and Oracle provided packages only allow a single version of the package to be installed at once. This might be fine for home systems but there are many use cases when you may need to install multiple versions of MySQL, and this may include different major or minor releases. Oracle do not support this (I’ve made a feature request for it) and it has caused some issues when working on upgrades. rpm/apt-get do allow for multiple packages to be installed (e.g. kernel) and also provide the “alternatives” package to allow for one of those to be designated the “current” package, so everything is there to do this. Oracle’s own installation practices (for it’s own database) recommend the database software be installed in a location and make it easy to then switch between different setups so the technique is obviously familiar to them.

    I’ve worked with upgrades going through MySQL 5.0 to 5.1 and 5.1 to 5.5, and shortly I will have to start the process again of moving from 5.5 to 5.6 so this issue will arise again and being able to have multiple versions installed at once would be most useful.

  32. I thought of another thing I find very annoying about RH; it pretty much always uses stock config mechanisms with monolithic single static files (e.g. httpd.conf). Debian and Ubuntu increasingly use .d folders, meaning it’s really easy to automate configuration, deploys, upgrades and cloning without having to worry about losing config changes, plus it makes reading configs much easier as you can leave stock options untouched (like the standard 1800-line php.ini) and have small files containing only your differences. Debian’s apache config and related tools are particularly brilliant.
    It’s not all rosy; the adoption of upstart runs counter to this trend, putting options inside files instead of using presence/absence of symlinks. systemd promises to bring sanity to process management, but we’re more likely to see that in RH before Debian (it’s already in Fedora), if only because RH was so late to the party in noticing how broken its current launch mechanisms are!
    I don’t buy that Ubuntu packages are old. Ubuntu current (Oneiric) uses 5.1.58, only 2 patch releases behind MySQL’s own packages, and that’s on an OS release frozen months ago. Precise is bundling 5.5.17, which isn’t old. That said, this is one reason I use Percona packages – the same versions are available across OS releases.
    I thought I’d double check on my RHN account to see what RH are pushing for RHEL. You’re going to laugh. The only packages they list are for MySQL 3.23!! The RHEL 6 marketing blurb mentions MySQL 5.1.47, but there’s no documentation on RH’s site or knowledge base and I can’t find any official package info; all par for the course in my experience. RH’s site threw a “redhat.com is temporarily unavailable. Please try back later” while I was looking for this, which doesn’t inspire confidence. Every time I look at RH it gets more farcical and less interesting; it’s becoming the XP/IE6 of the Linux world.

  33. Since everyone is mentioning their distro, let me put forward mine (using for non-production currently) — Arch — http://www.archlinux.org/. It has a much saner package manager and package signing (introduced quite late).

    I am using MySQL (5.6.4) on that now. Being bleeding edge, building MySQL it could use latest components like libevent, new kernel – 3.1.5, latest filesystem utilities etc.

    So I would recommend anything but debian (Sorry debianers: many packages are from time of dinosaurs unless you mean something like Sidux), RHEL etc for people trying out for non-production reasons. Also for benchmarking it should provide considerable insight (though benchmarking on enterprise distros make sense due to customers using them).

  34. Still wondering which .be dude you are talking about … Must be Kenny :)

  35. hippomegas says:

    Interesting article.
    I choose dpkg system quite than rpm files. I consider that apt is more authoritative than yum in external dependency. Tools like apt-cache, apt-file, aptitude are valuable.

  36. Hi.

    After choosing a distribution, are there specific settings that should be chosen for an OLTP DB?
    – file system? chunks? sizes? ext4 or xfs?
    – schedulers?

  37. Przemek says:

    One may argue that one Linux distribution is better or another. I would say let the people use what they like. But why the package maintainers don’t just write sane install and init scripts for MySQL? The most annoying for me part in Debian/Ubuntu is the /etc/mysql/debian-start and the ‘check_for_crashed_tables’ function (found in /usr/share/mysql/debian-start.inc.sh) which, among other things, does nasty select from information_schema. On an instance having thousands+ of tables it has to be disabled in order to not let the server suffer from I/O overload for a long time.
    Another one is ridiculous 14 seconds to start in /etc/init.d/mysql.
    I regret to say, but Percona’s edition of those scripts also includes those questionable features.

    Nevertheless I must say well done Percona for your great rpm and deb repositories!

  38. Dima Q says:

    I run a few lamp servers for many years now, so I can perhaps bring some light to long term stability of linux distros. I don’t use Percona though, only stock oss MySQL. I only had experience with Gentoo, CentOS and Arch.

    Gentoo is pretty decent, upgrades are possible, although if the server falls behind a couple years the intermediatory versions are gone from repository and it may take a day to find the matching upgrade path, e.g. old -> bash x -> portage x -> bash y -> glibc y -> new portage -> new mysql. It is something I’ve done several times, but if you cannot afford downtown this is a life saver. If you can afford downtime, it’s easier to unpack new stage3 over the installation. Downgrades are relatively simple with quickpkg, as long as MySQL binary format doesn’t change. Because gentoo compiles all the packages for you right on your server you can freely mix and match versions of LAMP components. An added bonus I had no problems with leap second either of the last 2 times it was added. Not in production anyway, I couldn’t even figure out what the world was so concerned about. Development server had java and mysql-5.5.14 take 100% cpu each, though both continued to work.

    CentOS is very fast to start using, however if you want newer MySQL, eventually you need newer CentOS, and the only officially supported CentOS upgrade strategy is… *reinstall*. Needless to say I’m not using this distro anymore for anything too important.

    Arch is great for desktop, however it doesn’t track versions of dependencies, only dependencies themselves. Which means you can easily break your system with libpng upgrade. And the Arch way is to synch your installation to trunk, which essentially means you are supposed to upgrade MySQL if you want to upgrade e.g. PHP. And you better upgrade kernel too, and then if you wanna make sure the server comes up after an unforseen power cut, you actually have to reboot to make sure. Great for desktop, not so for database servers.

    Ergo now all my database servers run Gentoo, production uptimes are 1.5y, 1.2y, 0.5y, 0.3y (ram+hdd upgrade), development uptimes were on the order of 1y before the recent power cut, both came up just fine.

  39. Suraj says:

    Hi Maciej,

    I came across this post while I am looking for answer to same question. CentOS or Ubuntu for MySQL 5.6?

    Opinions are divided on this. But your blog gave me compelling reason to opt for CentOS. But this blog dates back to 2011. Can you please confirm if same reasons that you mentioned in your blog hold true today also to prefer CentOS over Ubuntu?

    My own search on web gave me following points to think about:
    1. CentOS or Ubuntu don’t have differ much in performance. Use what you know best.
    2. CentOS is more stable, reliable and that’s why used by many webhosting companies
    3. 60% of users who work on production environments prefer CentOS over other linux distributions

    Your input would be appreciated greatly.

    Regards,
    Suraj

  40. Now the right question is: which is the best mysql fork ? ^^

Speak Your Mind

*