Do the slapcat on ldap2 and then delete the db files on ldap1 and then run
the slapadd. you will not get duplicates because all of the CSN's will be
the same. This is what I have done my migrations to the most recent
versions and doing my own builds. Works great that way.
Web Systems Administrator
O'Reilly Auto Parts
From: Marco Nett <nett(a)billiger-mietwagen.de>
To: Quanah Gibson-Mount <quanah(a)zimbra.com>
Date: 12/10/2013 11:00 AM
Subject: Re: Recovering from a Single-Node downtime in a Multi-Master
Sent by: openldap-technical-bounces(a)OpenLDAP.org
I'm running openldap 2.4.28.
If i just slapcat ldap2 and slapadd that to ldap1, won't i end up with
duplicates on ldap1?
is this the best way to do this?
2013/12/8 Quanah Gibson-Mount <quanah(a)zimbra.com>
On Dec 7, 2013, at 2:48 AM, Marco Nett <nett(a)billiger-mietwagen.de>
- I have two OpenLDAP slapd servers (ldap1 and ldap2) configured as
- The both have the exact same data between the mirrored
- If I create a new directory entry on one server, it immediately
gets mirrored to the second server.
- I'm happy.
- One LDAP-Master (ldap1) is down because of whatever.
- Changes to the directory are made on the LDAP-Master which is
still up (ldap2).
- Changes are not mirrored to ldap1 because it's down.
- I'm a little worried but still happy.
- ldap1 is back up and running, but it's directory is not up to
- The changes made to ldap2 in state 2 are not on ldap1 and aren't
getting replicated automatically.
- Mirroring again works fine, but ldap1 still doens't know about
changes made in state 2.
- I'm confused because I can't seem to find any information on how
to recover from this.
I couldn't just delete the directory on ldap1 and import the one
from ldap2 because the importing would also be mirrored to ldap2.
how would i go about recoverying from a downtime in a multi-master
What is the exact version of openldap are you running?
To recover, you could slapcat ldap2 and slapadd that to ldap1 so the db's
and csn's are sync'd up.
-- This message has been scanned for viruses and dangerous content, and is
believed to be clean. Message id: 9BEF7600D85.A1785
This communication and any attachments are confidential, protected by Communications
Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain
legally privileged material. If you are not the intended recipient, please return or
destroy it immediately. Thank you.