[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: N-Way Replication noob questions
Hi,
Le 21/04/2010 21:05, Siddhartha Jain a écrit :
Hi,
First, kudos to OpenLDAP team for the progress they have made with 2.4.
I am returning to use OpenLDAP after nearly a decade and it is
heartening to see all the new features even when going from 2.3 to 2.4
(As a side rant, it is painful to see Redhat/CentOS still ship 2.3.x.
RedHat might do it to push their own DS over OpenLDAP but why CentOS)?
1. From the OpenLDAP guide, I see that replication is setup to replicate
both – config and information trees.
a. With each master having a unique “ServerID”, does it mean that config
replication won’t overwrite certain attributes like ServerID?
No. Replication of cn=config includes all attributes, no exceptions
(unless configured otherwise, but I assume you're referring to the
example in http://www.openldap.org/doc/admin24/replication.html#N-Way
Multi-Master)
b. How are multiple “ServerID” values handled when the replication
config is introduced?
Each serverID value should have an associated LDAP URL. Thus, each
server can recognize which serverID is "it's own". For example :
serverID: 1 ldap://1.2.3.4/
serverID: 2 ldap://1.2.3.5/
slapd will then compare this URL to it's listeners passed with -h option
on startup, and use the corresponding serverID.
So you can put all necessary serverIDs in one config, and let it be
replicated everywhere.
c. What about credentials used for rootDN of various databases? Do they
get sync-ed too?
Yes.
2. What is the best way to setup a new master with empty databases?
Slapcat from an existing one and Slapdadd to the new one? Or, let
replication take care of it? Network traffic issues aside, my point is
how does timestamp matching work for non-existant objects (in the new
master vs existing). Or, put differently, how is deletion vs new/empty
database differentiated? Why wouldn’t replication consider the
non-existence of databases in the new master as all databases having
been deleted?
This is mostly covered by the syncrepl protocol.
I set up new servers by inserting a minimal config tree, that's only
purpose is to replicate the whole config tree from an existing master.
It's a simple config database with one syncrepl statement.
This pulls in all config, and then all data.
3. From 18.2.2.3 of the Guide “Arguments against Multi-Master replication”.
/4. //" If connectivity with a provider is lost because of a network
partition, then "automatic failover" can just compound the problem"/
Care to expand on this, please?
I assume this is referring to the fact that if your LDAP clients are
using n multi-master servers, and one goes offline or is inaccessible,
and LDAP clients fallback to another server, the overall load is going
to go up on the other servers, which may cause the system as a whole to
be unresponsive.
/5. //" If a network is partitioned and multiple clients start writing
to each of the "masters" then reconciliation will be a pain; it may be
best to simply deny writes to the clients that are partitioned from the
single provider"/
How so? If all masters are sync-ed with NTP tighly, then shouldn't this
issue take care of itself when a partitioned master(s) comes back online
and reconnect.
Yes. But the syncrepl protocol only reconciliates by copying whole
entries. So if during a network partition the same entry (let's say
uid=john,o=somewhere) is modified on two servers, and two different
attributes are changed, then when the two servers connect again, only
the most recent modification will be kept.
Hope this helps,
Jonathan
--
--------------------------------------------------------------
Jonathan Clarke - jonathan@phillipoux.net
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------