Alle 02:12, domenica 23 ottobre 2005, Ben Munat ha scritto:
> I was thinking about diverging from the mysql upgrade process
> described at
>
> http://www.gentoo.org/doc/en/mysql-upgrading.xml
>
> by one small bit. I'd rather not have the half-hour or so downtime
> while compiling mysql, so I was hoping to (after backing up my data)
> "emerge --buildpkg mysql" to get the 4.1 package all built. Then I'd
> stop mysql 4.0, unmerge it, "emerge --usepkgonly mysql" and restore
> my data.
>
> However, I have a feeling it won't work because the 4.1 ebuild
> probably checks for the existence of 4.0 on the system. If that's the
> case, could I maybe do the "export MYSQL_STRAIGHT_UPGRADE=1" step
> from the straight upgrade instructions?
>
> Of course, I'm not keen on doing any of this if there's some reason
> that vpopmail is not getting rebuilt with libmysqlclient.so.14...
> anyone have any luck with that yet?
==============
What I'm going to describe here has never been tested, take it with
care.
Discussion of the following procedure should be nice, the beaty of
opensource also is that 100 brains are always better than one.
==============
C: chroot steps
M: main system
C: Create a chroot, stage3 may suffice.
C: emerge mysql-4.1
C: change my.cnf :
port = 3307
server-id = 37
M: Flush tables with read lock or better, stop the server
M:C: copy the datadir in the chroot
(maybe cp -a /var/lib/mysql /chroot/var/lib/mysql)
optional:
If someting is going to _write_ in the time to come you will need to
setup the 4.1 server as slave (that's why there is the server-id = 37).
The procedure on how to do so is well documented on mysql web site.
M: release the lock or restart the server
C: start the server, may be as a slave of M:server, take a look at the
section STRAIGHT_UPGRADE
C: check consistence of data, check the cardinality of the indexes,
whatever come in mind.
M: for every mysql linked application you are using:
change the connection settings to work with
host=127.0.0.1
port=3307
use 127.0.0.1 instead of "localhost", otherwise mysql clients
use the sockets by default
hint: take a look at the output of the command
diff -Naur \
/usr/portage/dev-db/mysql/files/my.cnf-4.0.24-r1 \
/etc/mysql/my.cnf
Will show differences between the base and your my.cnf
M: no one is using this server right?
M: save somewhere /usr/lib/libmysqlclient*.so.1*
M: stop the server, unmerge it, emerge mysql-4.1
M: restore libmysqlclient*.so.1* in /usr/lib/
M: for every mysql linked application you are using:
emerge --onlydeps --one-shot cat/application
emerge --buildpkgonly cat/application
stop it
emerge --usepkgonly cat/application
start it
M: revdep-rebuild -pv --library=libmysqlclient.so.12
this will show a list of packages that still need to be emerged
Now you've two choices:
1) Leave the C:server in the chroot and so have it isolated from all the
other application and emerges.
In case you chose this road
mount -obind /chroot/var/run/mysql /var/run/mysql
so your apps still can access the server through host=localhost, using
the socket access, that's faster
2) the other is to bring again the server in the M: system, the
procedure to move it is the same as the previous one, reverting the cp
-a order.
Change every client setup to point to the right server.
Best regards,
Francesco
--
[email protected] mailing list
