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.
Link | February 16th, 2010 at 2:42 pm
For Yum:
nano /etc/yum.conf
Add:
exclude=mysql* MySQL*
There is no exclude trick for apt-get as far as I know…
Link | February 16th, 2010 at 2:49 pm
@Norbert,
This is correct, but my.cnf does not necessarily reside on /etc/. Especially if one has multiple installations.
@Randy,
Thanks!
Link | February 16th, 2010 at 2:55 pm
Fair point. But when the DBA wears multiple hats, like myself, yum/apt-get is best.
Link | February 16th, 2010 at 3:08 pm
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.
Link | February 16th, 2010 at 3:13 pm
@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”.
Link | February 16th, 2010 at 3:13 pm
@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.
Link | February 16th, 2010 at 4:45 pm
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 it is easier to apply those in massive environment (a lot of db server in production)
In this way, I still get the freedom, less pain, easier to collaborate with my coworker.
Link | February 16th, 2010 at 4:53 pm
@dheche
Just a quick note: installing a binary version does not require that you have gcc. It’s not a source distribution.
Link | February 16th, 2010 at 6:58 pm
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.
Link | February 16th, 2010 at 7:16 pm
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.
Link | February 16th, 2010 at 8:15 pm
@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.
Link | February 16th, 2010 at 8:21 pm
I have the same preference, for the same reasons. Well put.
Link | February 17th, 2010 at 2:32 am
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
Link | February 17th, 2010 at 3:20 am
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).
Link | February 17th, 2010 at 7:11 am
Linux MySQL distros meeting in Brussels « JZ Talk Blogger wrote:
[...] 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 [...]
Link | February 17th, 2010 at 11:27 am
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/
Link | February 17th, 2010 at 11:42 pm
Arjen,
Keep up the good work!
Link | February 18th, 2010 at 2:54 pm
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.
Link | February 18th, 2010 at 10:06 pm
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.
Link | February 19th, 2010 at 9:16 am
Log Buffer #179: a Carnival of the Vanities for DBAs | The Pythian Blog wrote:
[...] 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 [...]
Link | February 19th, 2010 at 7:50 pm
why “I consider a binary tarball to be the best MySQL installation format”.. If you on RHEL, why not get the MySQL RHEL RPMs?
Link | February 22nd, 2010 at 7:09 pm
@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?
Link | February 22nd, 2010 at 8:15 pm
Poll: what (minor) versions of MySQL should be supported by an open source MySQL related project? | code.openark.org wrote:
[...] 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? [...]
Link | April 2nd, 2010 at 9:30 am