Dave Horsfall wrote:
OpenLDAP 2.3.40 and 2.4.7.
Testing disaster recovery, such as a bulk update gone wrong, so need to
restore from last night's "slapcat" dump (we hardly ever write to the
directory, so it's no big deal losing a morning's work).
Delete an entry. Oops, I need it back. Stop the master (and slave), "rm
*.bdb __*", "slapadd -nX< slap.out", start the master and slave,
the slave, and the deleted entry has reappeared.
And then a miracle happens... This part of your message was far too terse to
figure out what you actually did.
You have a running master+slave, you deleted an entry that you want back. You
shut down both master+slave, you wipe out and reload the master using the
previous night's dump. You restart master+slave. So you only wiped out the
master's DB, and left the slave DB as-is?
Is this guaranteed behaviour i.e. the slave will always resynchronise
this case, or was I just lucky?
I think you were just lucky. In general the slave's syncrepl state is only
valid if the master's CSNs are monotonically increasing. By rolling the master
back to the previous night's state, and keeping the slave unchanged, the
slave's state gets invalidated (it's now newer than the master). There's no
explicit check for this condition. I suppose we could check for it, but
there's nothing particularly useful to do once it's detected, other than a
If it makes a difference, we use SyncRepl in
No. In either mode, the slave still goes through a normal refresh phase first.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/