I’ve written shortly on this before. I like yum; I love apt-get; I prefer not to use them for MySQL installations. I consider a binary tarball to be the best MySQL installation format (source installations being a different case altogether).
Why?
I use yum and apt-get whenever I can and for almost all needs (sometimes preferring CPAN for Perl installations). But on a MySQL machine, I avoid doing so. The reason is either dependency hell or dependency mismatch.
Package managers are supposed to solve the dependency hell issue. But package managers will rarely have an up to date MySQL version.
I’ve had several experiences where a simple yum installation re-installed the MySQL version. I’ve had customers calling me up when, having installed something with yum, MySQL would not work anymore.
yum install package-which-depends-on-mysql-server will install MySQL server on your system if it hasn’t been installed with yum. Are you on CentOS 5.0? You’ll get MySQL 5.0.22. Oh, did you already have a RPM installation for MySQL 5.0.81? Sorry – it’s just been downgraded, plus it won’t work anymore since the error messages file has been changed since then.
Don’t press ‘Y‘ too soon!
Things are slightly better with apt-get. I’ve encountered less situations where mysql-server was on the dependency list. Many times it’s just the libmysqlclient package or the mysql-common one.
But wait! Did you install mysql-common? Bonus! You get the elusive /etc/mysql/my.cnf file created, and there goes your server configuration. Future spawns of the MySQL server / clients will read from the wrong configuration file, and will probably fail to load.
Not to mention neither will help you out with multiple instances installation.
My argument
A sys admin recently argued with me that it was wrong of me to have the entire machine set up with yum, but have MySQL installed with binary tarball. He argued that it broke the entire setup. I expressed my opinion: on a MySQL dedicated server, MySQL gets to be prioritized. It’s special. It is the reason for the existence of the machine. I would imagine that same would hold for Apache on an Apache dedicated machine, for Sendmail on a Sendmail dedicated machine, etc. As a DBA, I want to have best control of the MySQL installation; I want to be able to upgrade minor versions quickly: I often find newer versions to solve bugs I was concerned with; I want to be able to install multiple instances; I want to be able to downgrade without having to remove and uninstall the previous version.
I want to have control. World domination aside, that is.
MySQL only looks for /etc/mysql/my.cnf when /etc/my.cnf doesn’t exist, so installing mysql-common shouldn’t affect your manually installed MySQL server.
For Yum:
nano /etc/yum.conf
Add:
exclude=mysql* MySQL*
There is no exclude trick for apt-get as far as I know…
@Norbert,
This is correct, but my.cnf does not necessarily reside on /etc/. Especially if one has multiple installations.
@Randy,
Thanks!
Fair point. But when the DBA wears multiple hats, like myself, yum/apt-get is best.
Even better is to create your own repository, with an up to date MySQL version in it. All packages that require mysql* will then happily use your own version, without breaking anything.