Hi all,
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?
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.
If I slapcat the old version and slapadd the data into the new version, 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.
My other option, since all servers run matching environments, would be 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?
Our site info:
All servers run Debian 4.0 (Etch) with near-as-dammit identically configured systems Kernel is 2.6.22 One master server, many slaves with identical databases. Replication is done by syncrepl Bandwidth to some sites is limited About 12000 records in the database
Thanks, Lesley W
Lesley Walker wrote:
Hi all,
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 always work.
If I slapcat the old version and slapadd the data into the new version, 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 be 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.
--On Friday, October 31, 2008 5:42 AM -0700 Howard Chu hyc@symas.com wrote:
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.
Of course, I would advise to go to 2.4.12 rather than 2.4.11, since it requires a reload to do that, too.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org