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.
This is a common problem, and there is no ideal solution, however your comment of a MySQL specific machine, MySQL gets special treatment is a very valid point.
However, so many organizations do not have a MySQL DBA, so the convenience of using one package installation process is a more practical solution for the System Administrator.
These leads to a number of issues, the two most significant are:
* Distro repositories are generally terribly outdated. You really need to either have your own repository or install the distro package from the MySQL downloads page.
* Upgrades/Downgrades are tied into the package management software, and this automatically starts and stops MySQL and this can be extremely annoying during an upgrade process.
The points on configuration file are valid, however you should always have a production management process to ensure versioning, so the issue is not the loss of the file, just the *possible* overriding. I’ve not found this an issue with rpm’s however so I’m not sure of the exact problem that was reported.
@Ronald,
With regard to configuration file: this relates to apt-get, not to RPM installations, where I did not find this to be an issue.
I have the same preference, for the same reasons. Well put.
Yum, uptodate, apt-get are sysadmin tools for managing dependencies and upgrades and clean rollout of new systems. The tend to handle glibc, vs python, vs ncurses very well, they tend to make a mess of MySQL.
If a sysadmin told me that everything had to be handled by yum, then I would tell them to build me a mysql package with a socket /tmp/mysql.sock
A datadir /somewhere/simple
A basedir /somewhere/simple
The sysadmin could look at the spec files of the standard rpms and perhaps come back with some suggestions, we negotiate and then we are done.
When upgrades happen, I ask the sysadmin to build a new package based on the new source. The RPM build process should not even have to involve a compile step, it could just be a wrapper around the binary tarball.
The tools are flexible enough for both the DBA and the sysadmin to work out an acceptable solution.
If not.. perhaps you can explain to him what /opt is for 🙂
—
Tom
I never had any problems when installing with official MySQL generic RPM binaries using YaST. But I have not yet tried on any SuSE version after 11.0.
We have some issues ourself with shared library compliance with very recent distros based on gcc 4.2-4.3. Not sure about every detail yet but the most recent RHEL and CentOS in particular seem to have more such problems than Fedora and OpenSUSE (I will not comment on non-RPM distros).