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.
@sime.
It’s easier when you’re also the sys admin and are in full control. Even then there’s the issue of repositories not having an up-to-date MySQL version.
It’s more difficult when others are allowed to “yum install”.
@sime
I empathize. I’m a team of one handling multiple OS’s, app development, apache, mysql, and even some oracle dependent services. App dev alone is consuming.
I’m hopeful that cloud services will someday be the solution.
I always use binary version (installed via yum) for my production. It is easier for me to recreate the same environment for devel/test before push it to production. If i want playing a bit or want to mess up something, i always do it in devel env. After i check all is fine then i push it to production. I’m prohibit myself for installing compiler (gcc) in production environment. All changes (patch, compiling option, etc) are managed in rpm spec file, so me and my coworker is easier to track what change, what already implement by other. Did I mention… Read more »
@dheche
Just a quick note: installing a binary version does not require that you have gcc. It’s not a source distribution.
After a few security issues in the mysql-server packages in Ubuntu 6.06 LTS and almost nonexisted support from cannonical we switched to binary tarball installs. It works great. Switching to MySQL enterprise is also easier when you’re using tarballs.
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… Read more »
@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… Read more »
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).
[…] 2008 MetaRegisterLog inRSS FeedComments RSSLinux MySQL distros meeting in BrusselsWhen I saw Shlomi’s post on why not to use apt-get or yum for MySQL, I thought immediately that his conclusions are quite reasonable. What you get from the Linux […]
The issue is not the fact that it’s repos, but the “outdatedness” of the mysql versions in distros.
Try the MySQL 5.0 and MariaDB 5.1 repos at http://ourdelta.org/
Arjen,
Keep up the good work!
I could be wrong about this, but I thought somewhere I read that it’s possible with apt-get to mark packages as installed, without them actually being installed, so the other packages which depend on them could be installed.
I could be wrong about this though.
Hi Brian,
apt-mark will let you mark packages as having been *automatically* installed, which means when you remove other packages that depend on said packages, they are automatically removed (as opposed to “I’ve manually installed thi package so do not remove it when you see no one using it”).
I’m not aware of marking non-existent packages as installed. But I’m not an expert on this.
[…] Data Charmer, reports on the Linux MySQL distros meeting in Brussels. He says, “When I saw Shlomi’s post on why not to use apt-get or yum for MySQL, I thought immediately that his conclusions are quite reasonable. What you get from the Linux […]
why “I consider a binary tarball to be the best MySQL installation format”.. If you on RHEL, why not get the MySQL RHEL RPMs?
@Singer,
I think I have it explained in the post.
Because:
1. They do not allow for multiple installations
2. yum will still remove such installations if it thinks it should
3. frankly, I don’t like it where RPMs have different conventions on different distros; not to mention different than deb packages.
/var/lib/mysql?
/var/run/mysql?
[…] How about supporting 5.0.22 (released almost 4 years ago, with almost 70 revisions since)? Would you expect an open source project to support this MySQL version because, say, this is the default version in your yum repository? […]
[…] To not yum or to not apt-get? […]
[…] To not yum or to not apt-get? […]