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

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@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.


What I'm going to try is to prepare packages of the ports I have to
upgrade on a dev/test server, and then install them with pkg_add: is
that the "right way" ? 

Thanks in advance for your advices & regards,
Olivier

On 05/22/07 21:03, Olivier Mueller wrote:
> 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:
> 
Oliver,

try something like:

portupgrade -o databases/mysql50-client mysql-client
portupgrade -o databases/mysql50-server mysql-server

Make sure you're doing a backup of your SQL data *before* you're 
doing this as the MySQL server (AFAIR) is being halted at upgrade 
time (short after compiling everything has finished).

The portupgrade commands mentioned above might just be half of the 
work as other ports might need an upgrade, too. I did the same some 
weeks ago but can't remember if there was any extra work needed.

HTH

Volker

On May 22, 2007, at 12:03 PM, Olivier Mueller wrote:
> 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?
Pretty much as you suggest below:
> 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.
>
> What I'm going to try is to prepare packages of the ports I have to
> upgrade on a dev/test server, and then install them with pkg_add: is
> that the "right way" ?
You have a build box that you generate new tarballs of the packages  
you want to update (via "make package", "make
package-recursive",
"portupgrade -p", etc), which you can then test and make sure they  
behave sensibly, and then use these to rapidly update your production  
machines with minimal downtime.

-- 
-Chuck

Olivier Mueller wrote:
> Isn't there a better way?  How do you handle such cases? 
We go to extra lengths and allow only pkg installs on servers. That way
we are sure, that no random library pollution takes place. It also makes
stuff better reproducable.

Sadly packages are somewhat neclected and there is still no good
pkg_update tool
> What I'm going to try is to prepare packages of the ports I have to
> upgrade on a dev/test server, and then install them with pkg_add: is
> that the "right way" ? 
A good way would be to test this very update with packages on a test
box. That is, install mysql4, produce your mysql5 packages somewhere
else (or use a chroot or jail). Then see if pkg-updating works for
mysql.

Ulrich Spoerlein
-- 
"The trouble with the dictionary is you have to know how the word is
spelled before you can look it up to see how it is spelled."
-- Will Cuppy