October 26, 2014

Distro Packages, Pre-built Binaries or Compile Your Own MySQL

I’ve been helping customers deploy and maintain MySQL (and variants) for the last couple of years and it has always been interesting to hear customer thoughts on how they want their servers installed. It has also been asked many times not only by our support and consulting customers, but widely from different forums and blogs – how should I install MySQL on my server and what pros and cons does each have?

Package Managers (apt, yum, yast, dpkg, rpm)

This has the most votes anywhere. True, why would you rather go through the hassle of building and/or manually configuring your binaries when you can simply yum -y install Percona-Server-server or apt-get install percona-server-server? Using OS specific packages comes with a lot of advantages, one being they have been rigorously tested with the other components of your operating system. Take for example Ubuntu, the MySQL packaging team does not always include with every release the latest and greatest, simply, select bug fixes especially security bug fixes are incrementally backported with each update leaving some if not all incompatible bug fixes to avoid breaking other dependent functionality within the OS.

Another advantage is the simplicity of maintenance, package managers like apt and yum can test and resolve dependencies before even installing the packages and avoid any extended downtime. Although packages provided from your OS’ base repositories often are not up to date, 3rd party specialized repositories and package providers like the ones provided by Percona, MariaDB and Oracle fills this gap with updated versions.

On the other hand, not everyone agrees on what server operating system to use, so trying to maintain similar versions across your environment, while keeping in check that each server does not break any dependency with packages coming from difference repositories along the way can become difficult, not to mention that package managers themselves can break!

Pre-built Binaries (binary tarballs)

Installing pre-built binaries take a little more leg work, but its only several commands more than installing from your OS or 3rd party repository. Running MySQL with pre-built binaries is seldom to run into dependency problems, but then you also have to be careful when running on systems with incompatible core dependencies like glibc or libaio. You may be able to run binary packages of the latest version on Redhat Enterprise Linux 3 (yes, ridiculous, but for the sake of argument) but the problems can be subtle and silently corrupt your data.

Aside from not dealing with dependency issues, running with binary packages allows you to upgrade/downgrade easily without going through the hoops of you package manager of choice. This can be as easy as stopping MySQL, updating symlinks or your my.cnf basedir, starting MySQL and running mysql_upgrade. Unlike package managers, you do not have to worry about accidentally updating from one version to another because you forgot to exclude packages from automatic update, manually installed pre-built binaries is less likely to be replaced/overwritten during an update by simply keeping package folders on unique directories.

Lastly, running your MySQL server from pre-built binaries does not prevent you from installing other MySQL packages on the server for other dependencies i.e. mysql-libs dependency for postfix, crontab, etc on RHEL based distros.

Custom Built Binaries (compile your own)

Specialized needs, requires specialized solutions, and in the open source world, with the freedom to customize software to fit every organizational needs, compiling custom MySQL binaries takes a third of the options. If you develop and integrate custom features or patches, need to alter MySQL’s default behavior i.e. disabling and totally disallowing use of query cache or increasing maximum total number of indexes per table from 64, or maybe your engineering mantra simply wants to take advantage of bleeding edge hardware, kernel or core libraries. This all makes sense, but requires some engineering effort for continuous integration – yes if you have only one or 2 sets of patches the job is trivial – however for companies like Google, Facebook and Twitter the job is enormous.

Sometimes, custom building is not the last solution at all, if you have problems with how MySQL behaves with your application, maybe it would also make sense to look the other way around – can you make your application behave properly with MySQL? A paradigm shift like this can save your team tons of hours spent on planning, testing, troubleshooting (rinse and repeat) cycle when maintaining your custom builds.

My Personal Choice

While everybody would agree that they should choose whatever their team/company is comfortable with and what is appropriate for their needs i.e. are you using for testing or more permanent install? – my personal preference amongst the 3 would be pre-built binary packages. It enables finer control over installations/upgrades, it also allows to easily switch between appropriate versions if called for when troubleshooting for problems and not spend too much time on switching, rather focus on the problem. While some of us is more comfortable with packages deeply integrated with our operating system, I can say I am more experienced with handling integration hence my personal choice.

Not all environment is created equal and I hope I’ve provided a perspective. Now, how do you prefer your MySQL server installed?

UPDATE: Peter and Sergei suggested on the comments that 3rd party specialized repositories might have been not explicitly included. This is true, my mistake as I have not been clear and I have made a few modifications to reflect those points – however, generally we still have only 3 options.

About Jervin Real

Jervin is a member of Percona's Rapid Response Consulting team. When you come to Percona for consulting, chances are he'll be greeting you first. His primary role is to make sure customer issues are handled efficiently and professionally. Jervin joined Percona in April 2010.

Comments

  1. Nils says:

    I tend to use distro packages, if I need something changed in the code or a newer release I can still buil another package. The problem with the pre built binaries or source code is that once you deviate from what the package manager does you will have to install everything that uses MySQL manually because the package manager has no knowledge of your working MySQL installation – even worse when you forget to prohibit it from installing MySQL and it installs another copy.

  2. Jervin Real says:

    @Nils,

    Good point, although the most I can think of if an OS package requires something MySQL, it will be the shared libraries and you can either chose to install via your package manager or configure to point to what is included with the pre-built binaries. The former is more convenient while you still get the benefits of pre-built binaries. I can’t think of any that depends on the “mysql server” package (I know there are, and they should be punished) – other packages like Cacti on Ubuntu are sensible enough to allow you to configure the MySQL part manually.

  3. Sergei Golubchik says:

    Another option – something between distro and pre-built packages, would be to use a third-party package repository, understood by your distro package manager. There’re Percona yum and apt repositories and MariaDB yum and apt repositories. You only need to register them in your package manager, and you can use pre-built binaries, but enjoy all the services of your package manager, such as automatic dependency tracking, easy upgrades, etc.

  4. Jervin,

    I would second Sergei here. I think you omit the most practical choice – using “third party” repository. If MySQL is very important part of your environment (which it is on database servers) running distro packages can be poor choice as they are often lagging behind significantly with software release updates.

    Second I’m not sure in which category do you put the binaries which are not provided but distro but specially build for it. Oracle, Percona, MariaDB all provide downloadable binaries build specifically for major Linux versions which is something very good to use if you’re updating manually as they are tested to be compatible with specific OS in question.

    I would NOT use “generic Linux Binary” as it is not really tested for compatibility with all variety of Linux operation systems. I also would not compile my own binary unless I’m really patching something or setting custom compile time limits. Many people think they can do better build themselves by changing optimizer settings etc which in fact may result in pretty poorly build binaries ranging from debugging enabled (and slow) to simply unstable.

  5. Greg says:

    I definitely prefer the pre-built binaries but to use them in our environment I have to pass ‘–noscripts’ to rpm, mainly because we use a different user than ‘mysql’. For example,

    rpm -Uvh MySQL-shared-compat-5.5.27-1.rhel5.x86_64.rpm
    rpm -Uvh MySQL-client-5.5.27-1.rhel5.x86_64.rpm
    rpm -Uvh –noscripts MySQL-server-5.5.27-1.rhel5.x86_64.rpm

    I then manually install our version of /etc/init.d/mysql and /usr/bin/mysqld_safe.

    Not elegant but it’s been working for 12 years now.

    Greg

  6. Jacky Leung says:

    Do you think it is a better and more viable option to create and maintain your own package repository? Recently the company I work for launch new servers with apt-get, it installed the latest Percona server from the Percona repository, and it got hit by the partition bugs in 5.5.24, and server crashing bugs in the 5.5.25a. Which lead to forcing us downloading package manually off the Percona site and install them manually

    In my opinion, I think it is better to not install any new version if the current installed version is working fine. I probably prefer to have the repository stay in the version that is working for me until I find it is necessary to do upgrade

  7. Jacky,

    What is quite common approach is to create your own repository to maintain company wide “baseline” of software you’re running so you only update when you chose it. I would say it is especially important for critical software what you use a lot, which can be MySQL, PHP etc for which you may not want to have upgrade happen automatically without you testing it first.

Speak Your Mind

*