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?
Distro Packages
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. On the other hand as easy as it is to upgrade, getting packages for the latest version with a critical bugfix your organization needs can be difficult and sometimes leads to frustration – that being said, you are in the mercy of the package providers with when and how they release with newer versions.
Additionally, 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
Installing pre-built binaries take a little more leg work, but its only several commands more than installing from your OS 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
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.
Not all environment is created equal and I hope I’ve provided a perspective. Now, how do you prefer your MySQL server installed?
PlanetMySQL Voting: Vote UP / Vote DOWN