Quick question:
State 1: - I have two OpenLDAP slapd servers (ldap1 and ldap2) configured as Multi-master. - The both have the exact same data between the mirrored directories. - If I create a new directory entry on one server, it immediately gets mirrored to the second server. - I'm happy.
State 2: - 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.
State 3: - ldap1 is back up and running, but it's directory is not up to date. - 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. right? how would i go about recoverying from a downtime in a multi-master setup?
On Dec 7, 2013, at 2:48 AM, Marco Nett nett@billiger-mietwagen.de wrote:
Quick question:
State 1:
- I have two OpenLDAP slapd servers (ldap1 and ldap2) configured as Multi-master.
- The both have the exact same data between the mirrored directories.
- If I create a new directory entry on one server, it immediately gets mirrored to the second server.
- I'm happy.
State 2:
- 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.
State 3:
- ldap1 is back up and running, but it's directory is not up to date.
- 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. right? how would i go about recoverying from a downtime in a multi-master setup?
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.
--Quanah
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@zimbra.com
On Dec 7, 2013, at 2:48 AM, Marco Nett nett@billiger-mietwagen.de wrote:
Quick question:
State 1:
- I have two OpenLDAP slapd servers (ldap1 and ldap2) configured as
Multi-master.
- The both have the exact same data between the mirrored directories.
- If I create a new directory entry on one server, it immediately gets
mirrored to the second server.
- I'm happy.
State 2:
- 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.
State 3:
- ldap1 is back up and running, but it's directory is not up to date.
- 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. right? how would i go about recoverying from a downtime in a multi-master setup?
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.
--Quanah
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.
Eric Speake Web Systems Administrator O'Reilly Auto Parts
From: Marco Nett nett@billiger-mietwagen.de To: Quanah Gibson-Mount quanah@zimbra.com Cc: "openldap-technical@openldap.org" openldap-technical@openldap.org Date: 12/10/2013 11:00 AM Subject: Re: Recovering from a Single-Node downtime in a Multi-Master Setup Sent by: openldap-technical-bounces@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@zimbra.com
On Dec 7, 2013, at 2:48 AM, Marco Nett nett@billiger-mietwagen.de wrote:
Quick question:
State 1: - I have two OpenLDAP slapd servers (ldap1 and ldap2) configured as Multi-master. - The both have the exact same data between the mirrored directories. - If I create a new directory entry on one server, it immediately gets mirrored to the second server. - I'm happy.
State 2: - 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.
State 3: - ldap1 is back up and running, but it's directory is not up to date. - 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. right? how would i go about recoverying from a downtime in a multi-master setup?
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.
--Quanah
-- 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.
--On Tuesday, December 10, 2013 11:08 AM -0600 espeake@oreillyauto.com wrote:
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.
Huh?
The CSNs contain the server IDs. Servers ignore their own changes.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
W dniu 10.12.2013, 18:12, Quanah Gibson-Mount pisze:
--On Tuesday, December 10, 2013 11:08 AM -0600 espeake@oreillyauto.com wrote:
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.
Huh?
The CSNs contain the server IDs. Servers ignore their own changes.
I admin I was not (yet!) forced to recover OpenLDAP master server from serious disaster.
How should I recover any single master in topology where total number of masters is more than two - and modifications are made across all of them? I'm using LTB project package - its start+stop script is also able to make backups of server configuration and all databases.
Will replication manage to bring recovered master up-to-date based on slapadd from output of slapcat from *any* of other masters? Or more proper way is to restore last backup of configuration and database and let replication do the rest? Of course preventing clients to contact LDAP server until replication finishes is a must in such a situation.
Best regards, -- Olo
--On Tuesday, December 10, 2013 8:58 PM +0100 Aleksander Dzierżanowski olo@e-lista.pl wrote:
Will replication manage to bring recovered master up-to-date based on slapadd from output of slapcat from *any* of other masters? Or more proper way is to restore last backup of configuration and database and let replication do the rest? Of course preventing clients to contact LDAP server until replication finishes is a must in such a situation.
I have always just slapcat'd one of the other masters if I lost a master so it would have a much more current snapshot after reload.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Aleksander Dzierżanowski -
espeake＠oreillyauto.com -
Marco Nett -
Quanah Gibson-Mount