Lesley Walker wrote:
I looked in the online version of the Admin Guide for upgrade
instructions, but they don't seem to have been written. So I have come
to the experts for guidance.
I have successfully compiled and installed the new version, and run it
as a slave in our existing system. I allowed to create its database via
syncrepl, and that worked a treat (although it took longer than I
expected). It's been happily running for a while and I have no issues.
My question is really, what's the best way to approach the upgrade of
the master server?
Same as any other upgrade: slapcat the old database to LDIF, then slapadd with
the new installation.
Since we're going from BDB4.2 to BDB4.4, I assume it wouldn't
be be a
good idea to just plug the existing database into the new code.
No, that pretty much never works. slapcat/slapadd is the only method that will
If I slapcat the old version and slapadd the data into the new
will that cause the entire database to be resynced out to all slave
servers? We have about 100 slave servers, and the thought of
(effectively) resetting all their sync cookies all at once makes me shudder.
No. The sync state is part of the database. When you slapcat it, the sync
state is part of the LDIF. When you slapadd again, the sync state is loaded
exactly as before.
My other option, since all servers run matching environments, would
to take a copy of the database from a replicated 2.4.11 slave and plug
that straight in (having disallowed updates and replication, and taken
any other safety measures I can think of). Would this be a stupid risk,
or would you expect it to work okay?
There are ways to do that. Read the BerkeleyDB documentation if you want to
take that route. It involves a lot more commands, it's really quite messy.
Just use slapcat/slapadd.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/