minimizing downtime on upgrades? (for example: mysql 4.1 -> 5.0 or php)

Andrew Pantyukhin infofarmer at FreeBSD.org
Tue May 22 19:30:31 UTC 2007


On 5/22/07, Olivier Mueller <om-lists-bsd at omx.ch> wrote:
> Hello,
>
> Some "freebsd-beginner" questions about how to maintain a production
> server up to date day after day, with a practical example: now I have
> to update a 6.1-based server from mysql 4.1 to mysql 5.0, minimizing
> the downtime during the upgrade.
>
> In the past under other OS'es I would have taken the mysql source,
> compiled the whole, and then on upgrade time:
> - stopped the services (httpd, etc.)
> - mysqldump of all tables
> - stopped mysqld
> - removed the old version (+backup)
> - 'make install'ed the new one
> - started mysqld
> - imported the db and restarted the other services
> -> 2-3 minutes downtime, depending on the size of the databases
>
>
> Now I can't really do that under FreeBSD: if I want to prepare (just
> "make" in the ports directory) the mysql50-server part, it answers:
>
> [root at prod1 /usr/ports/databases/mysql50-server]# make
> ===>  mysql-server-5.0.41 cannot install: MySQL versions mismatch:
>   mysql41-client is installed and wanted version is mysql50-client.
> *** Error code 1
> Stop in /usr/ports/databases/mysql50-server.
>
> So I can only do that after the installation of mysql50-client, which
> means all the services will have to be stopped during the compilation of
> mysql50-server, which usually takes some time.
>
> Isn't there a better way?  How do you handle such cases?
>
> Same questions for php upgrades: on php5 upgrade, all the other php5-*
> packages have to be compiled too, and keeping the webserver running
> during this time is probably not the best idea.

You raise a very good question. Concurrent versions have
been a major feature of some enterprise-class package
management systems for years now. Through local hacks,
FreeBSD ports only enable us to achieve that in a tiny
amount of cases (e.g. you can have multiple [but fixed]
versions of autoconf installed at the same time).

To make the feature available on a larger scale, we'll
need to rework much of our current infrastructure. E.g.
most probably we'll have to install ports into dedicated
directories.

This springs has already reignited many talks about the
ports system. Let's hope we'll see some substantial
results by the end of the year.


More information about the freebsd-ports mailing list