[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Restoring with SLAPADD

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, check
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 in
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 full refresh.

If it makes a difference, we use SyncRepl in "refreshAndPersist" mode. 

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/