[Date Prev][Date Next]
Re: Flexible multi-master support.
I haven't had time to look at this patch, but I thought I
would give you a little feedback on why the multi-master
replication solutions I've seen to be experimental.
First, the X.500 service model (as used in LDAP provides
for atomic updates to information held at THE master server
and information visible at shadow (slave) servers may
only have transient inconsistency (that is, the shadow
copy must eventually reflect the state of the master
copy). A proper multi-master schema provides transactional
consistency across all masters, that is, an update operation
must either successfully update all masters or no masters
AND the result of that update must be indicated to the
client. To do less would violate the service model will
break numerous existing directory applications.
Secondly, where implementations have experimented with looser
consistency (e.g., broken clients), they will run into
reconciliation failures. An implementation without automated
reconciliation procedures, such as our current code, would
not be terrible useful in environments opting for looser
consistency multi-master replication.
One has to wonder whether multi-master is the right
solution to the problem. If the problem is write bandwidth,
multi-master will actually make the problem worse. If its
fail-over, fail-over can be resolved without multi-master.
If its locality of write, then "shared master" or "floating
master" might be a better approaches.
(Shared master is where the authority of a naming context
is shared amongst a collection of servers, but where each
entry has but one authoritative server. Floating master is
a variant of shared master approach where authority can
I like to note that Jong is working on new single master
replication system (consumer initiated, producer pushed)
based upon our LDAP Sync operation proposal to the IETF.
It likely could be extended to support "shared master"
or "floating master".
At 01:33 PM 3/25/2003, Gertjan van Wingerde wrote:
>I've just uploaded a patch to ftp.openldap.org which I would like to have
>discussed prior to submitting it via the ITS-system. This patch implements a
>more flexible way of doing multi-master setups than the currently implemented,
>but disabled at compile-time, symmetric multi-master setup. The patch does the
>following 3 things:
> 1. It allows the user to configure an identifier for each replica in the
> slapd.conf file.
> 2. It allows the user to configure multiple updatedn DN's in order to
> separate LDAP replication traffic from each other (e.g. to handle
> replication traffic coming from one DN (= server) different from LDAP
> replication traffic coming from an other DN (= server).
> 3. It allows the user to configure per updatedn the set of replica's
> the incoming replication traffic should be replicated to.
>The reason for implementing this is twofold:
> 1. It allows me to set up an LDAP server tree on one site, which efficiently
> replicates data across a large farm of LDAP servers.
> 2. It allows me to set up a multi-site, geographically distributed, LDAP
> solution, in which the replication traffic only has to go once over the
> WAN link between the sites.
>The functionality is implemented fully backwards-compatible, i.e. all existing
>LDAP configuration still behave as before.
>Please let me know what you think of it, whether anything is missing in the
>patch and whether you would consider this approach for inclusion into the
>mainline OpenLDAP source-tree.
>The patch is available under: