Re: Fault-tolerance for master OpenLDAP server

[Quanah Gibson-Mount <quanah@stanford.edu>]

--On Wednesday, August 31, 2005 11:43 PM -0400 Samuel Tran <stran@amnh.org> 
wrote:


> Quanah,
>
> This part is the one I was the least concerned about.
>
> My two problems are:
>
> 1) After a failover to the secondary master, what should we do with the
> primary? What if the primary comes back online? The simplest solution is
> provided by that article pointed out by Gary: prevent the failed node to
> re-acquire the virtual IP.
>
> 2) I would like to use syncrepl as the synchronization mechanism between
> my master and slaves. Let's assume my primary master fails and one the
> slaves takes over after being reconfigured as a master. Will
> synchronization work between the new master and the other slaves? I am not
> sure about that because of what I read in the admin doc:
>
> "Syncrepl keeps track of the status of the replication content by
> maintaining and exchanging synchronization cookies. Because the syncrepl
> consumer and provider maintain their content status, the consumer can poll
> the provider content to perform incremental synchronization by asking for
> the entries required to make the consumer replica up-to-date with the
> provider content. Syncrepl also enables convenient management of replicas
> by maintaining replica status. The consumer replica can be constructed
> from a consumer-side or a provider-side backup at any synchronization
> status. Syncrepl can automatically resynchronize the consumer replica
> up-to-date with the current provider content."


This is what I'd generally do:

Use a load balanced name for the master (I in fact do this).

If the primary master dies, promote a replica to be a master.  Assign the 
load balance name for the master to the promoted replica.

When you get the old master repaired, bring it back online as a replica, to 
replace the old replica that got promoted.

On the master, the cookie is stored in the root entry of your tree in the 
contextCSN attribute.

In the replica, the cookie is stored in root entry of your tree in the 
contextCSN attribute.

Therefore, assuming all replica's got the last change propagated out by the 
master before it died, they should accept updates from the new master.

Master search:

ldap-dev0:~> ldapsearch -h ldap-dev0 -s base -b "dc=stanford,dc=edu" +
dn: dc=stanford,dc=edu
structuralObjectClass: organization
entryUUID: a504e0c4-9029-1029-9e4c-98dee611ff4f
creatorsName: cn=Manager,dc=stanford,dc=edu
modifiersName: cn=Manager,dc=stanford,dc=edu
createTimestamp: 20050724005725Z
modifyTimestamp: 20050724005725Z
entryCSN: 20050724005725Z#000001#00#000000
contextCSN: 20050829181627Z#000002#00#000000
entryDN: dc=stanford,dc=edu
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE


Replica search:

dn: dc=stanford,dc=edu
structuralObjectClass: organization
entryUUID: a504e0c4-9029-1029-9e4c-98dee611ff4f
creatorsName: cn=Manager,dc=stanford,dc=edu
modifiersName: cn=Manager,dc=stanford,dc=edu
createTimestamp: 20050724005725Z
modifyTimestamp: 20050724005725Z
entryCSN: 20050724005725Z#000001#00#000000
contextCSN: 20050829181627Z#000002#00#000000
entryDN: dc=stanford,dc=edu
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE




--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin