7:25 p.m.
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.
--
Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch)
Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU
7:41 p.m.
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 DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch)
Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU
11:44 p.m.
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/
12:44 a.m.
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.
5:02 a.m.
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.
--
-- 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/
5766
days inactive
5766
days old
openldap-software@openldap.org
4 comments
3 participants
participants (3)
-
Dave Horsfall -
Howard Chu -
Michael Ströder