[Date Prev][Date Next]
Re: Feature request: multimaster
- To: Pierangelo Masarati <firstname.lastname@example.org>
- Subject: Re: Feature request: multimaster
- From: Morteza Ansari <email@example.com>
- Date: Tue, 08 Feb 2005 00:02:09 -0800
- Cc: openldap-devel <openldap-devel@OpenLDAP.org>
- In-reply-to: <41FB67EA.firstname.lastname@example.org>
- References: <41FB67EA.email@example.com>
- User-agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
Wouldn't conflict resolution be a must for this? Think of a provider
that is not reachable by the rest of the DSAs, not because it is down,
but due to a segmented network. You will end up with true multimaster
where changes are going to be taken on both of them which may result in
Pierangelo Masarati wrote:
We are in the process of investigating the feasibility of adding the
above capability to slapd.
First of all a fundamental clarification: multimaster here means that
there is a pool of DSAs that are in sync (e.g. by syncrepl). Each time,
only one of them acts as the provider, but they all know of each other.
As soon as the provider is not reachable any more, the consumers elect
another provider among the remaining DSAs in the pool, much like
replication for Berkely DB does, selecting the one with the latest
contextCSN or, in case, resolving the conflict somehow (e.g. a ballot
with random sleep). Appropriate measures are required to welcome the
original provider back in the pool: it should become a consumer and sync
with the new provider, but conflicts might occur if it was modified
after losing providership.
This essentially needs the configuration of the replication (i.e.
syncprov overlay and mostly the syncrepl directive, updatedn and
updateref) to be modifiable run-time, via some mech to be defined.For
the purpose, unless back-config is available any soon, I'd like to
investigate the possibility to temporarily delegate this to
back-monitor, e.g. by exposing the syncrepl and updateref directives and
allowing them to be modified via protocol. Despite promotions/demotions
should be performed internally, manual intervention via protocol should
still be possible.
The rest of the multimaster functionality, that is the capability to
accept writes anywhere in the pool, should be delegated to the chain
overlay, in order to guarantee the consistency of the operation in a
tansparent manner, at the cost of a delay between the successful return
of the update and the actual appearance of the changes on the database.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497