To not yum or to not apt-get, that's NOT the question.

Over at the OPenARK blog Shlomi Noach argues that using apt-get or yum to install your MySQL instance will one day most likeley break your MySQL setup. Depdendencies, distros not shipping the MySQL version you want to use and on some distro's indeed the mysql vs MySQL issue, agreed, it all makes things less trivial.

However why give up a clean packaged system if there are other ways out ?

First of all by claiming that such an installation can break a working production environment looks to me like admitting you don't have a split development, production environment and that rather than testing stuff upfront indeed you just hack a long in production.

So rather than using a tarball for the MySQL instance an --force to satisfy the missing dependencies (hence also cluttering your system) , a much cleaner and less error prone setup is to only deploy from your own , self controlled repository , in which you only allow tested packages, most probably not the distro based package , hence packages that won't break your setups ;) But still you will be using apt or yum and deploying rpm's and debs , perfectly satisfying dependency needs.

Apart from that .. watch out for Banquise .. :) Coming to your favourite distro soon..

Comments

Greg's picture

#1 Greg : Use --noscripts option

I always install MySQL Server using the --noscripts option to rpm. I then manually do the stuff the scripts would have done when I'm ready.


Shlomi Noach's picture

#2 Shlomi Noach : complex either way?

Hi Kris,

How complex is it to manage your own repository?
I'm asking sincerely, since this is not something I ever did.

It seems to me (let me know if I'm wrong) that it's not less complex than having MySQL installed using tarball.

Neither solution is pretty nor ideal. I'm not sure, then, that tweaking your repository (how much damage is done if something goes wrong there?) is any easier.

I'm pretty certain that an expert sys admin would say managing your own repository is a piece of cake. An expert MySQL DBA has little trouble with installing from tarball.

Best to compare on non-expert level.

Regards,
Shlomi (Open-Ark)


Kris Buytaert's picture

#3 Kris Buytaert : piece of cake

Shlomi ,

It indeed is a piece of cake :)


Simon J Mudd's picture

#4 Simon J Mudd : Packaging means different things to different people

Yes and no in response to your comments.

There's nothing inherently wrong with using packages, but they need to do what you want. Sometimes, however, the original packaging design may do things you don't like and that's not helpful.

Also in an environment where you have more than one database instance running on the same host, most rpm packages are "broken", assuming that there is only one instance and only one package. That is not always true.

I work in an environment where we have multiple instances. You can work around the packaging problem if all instances run the same version, but if you want to first test a new version while running an older version, that's hard with most rpm packages. I'm not sure if apt packages are better.

The Linux kernel packages seem to be more suitable: you can install more than one package at once, and each one is isolated. Obviously you can't run more than one kernel at once, but running more than one mysqld is easy as long as you put your datadir somewhere different for each instance.

Then if you're looking at upgrading 5.0 to 5.1 be aware of some of the silly hoops you have to run around: you need to start mysqld 5.1 to run the 5.1 mysqlcheck to check which tables need upgrading, and in theory to do this you have to downgrade again back to 5.0 to do the dump, and upgrade again to import those dumps back in. Silly. If you can only have one version of the mysql package installed at once that becomes frustrating.

RedHat and MySQL rpms also insist on starting a MySQL instance when the package is installed. That's not sometimes very helpful if you're going through an install process, or want to "tweak" certain things before putting the server live (a slave will immediately try to talk to the master and start replicating), yet there's still no fix possible to tell the package: please don't start me while installing or upgrading. Not hard to do and possibly not an issue for a lot of people, but for some of us this behaviour is not ideal.

So in general I agree. Packaging is good, but I think that the MySQL packaging I've seen is not intended for people who work in a slightly more complex setup. However, we are the people who really use MySQL and actually need these features.

I'm still pondering over whether to go back to mysql binary tar balls and use something like the MySQL Sandbox scripts (or something similar) to manage multiple instances. This software actually works quite well, even if the setup is a little unconventional for managing production or development MySQL instances.

In the end I'd like the packages to install into a separate location, and it to be possible to have multiple versions installed at once, and then have some simple way to manage more than one instance and to be able to switch between those instances that are running on the same box.

However, I see that changing from the current practice is probably too much, which leads me to assume I'll have to come up with my own adhoc "different" solution. You may do the same thing using your solution which different again from mine.


Fatal error: Call to undefined function drupal_get_path() in /var/vhosts/www.krisbuytaert.be/htdocs/blog/includes/module.inc on line 285