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.
Is this guaranteed behaviour i.e. the slave will always resynchronise in this case, or was I just lucky?
If it makes a difference, we use SyncRepl in "refreshAndPersist" mode.
On Thu, 21 Feb 2008, Dave Horsfall wrote:
Is this guaranteed behaviour i.e. the slave will always resynchronise in this case, or was I just lucky?
Never mind; I cannot reproduce it (something to do with contextCSN?) so I must've been lucky...
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.
Dave Horsfall wrote:
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.
If you need back a single entry or just a few entries I'd rather try to extract them from slapcat-generated LDIF, remove the entryCSN attributes and slapadd them, not the whole database. From my understanding new entryCSN would be generated and the contextCSN would be increased. Howard, is this correct?
Still I'd use slapadd if you can accept the down-time needed instead of normal ldapadd since the entryUUID and other operational attributes are preserved which can be a real requirement in case some other data syncing is based on that. (Using ldapadd with Relax Rules Control formerly known as Manage DIT control would be another option to restore the entry with the operational attributes.)
Ciao, Michael.
Michael Ströder wrote:
Dave Horsfall wrote:
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.
If you need back a single entry or just a few entries I'd rather try to extract them from slapcat-generated LDIF, remove the entryCSN attributes and slapadd them, not the whole database. From my understanding new entryCSN would be generated and the contextCSN would be increased. Howard, is this correct?
Yes, a new entryCSN would be generated if you remove the old one. And yes, if you use slapadd -w the contextCSN will be updated as well.
Still I'd use slapadd if you can accept the down-time needed instead of normal ldapadd since the entryUUID and other operational attributes are preserved which can be a real requirement in case some other data syncing is based on that. (Using ldapadd with Relax Rules Control formerly known as Manage DIT control would be another option to restore the entry with the operational attributes.)
Ciao, Michael.
openldap-software@openldap.org
-
Dave Horsfall -
Howard Chu -
Michael Ströder