[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Feature request: multimaster
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.
Since this is something we'll probably need as well, by all means go
ahead with it. The back-config work has been delayed, and I don't see it
being ready very soon. Hopefully with syncrepl settling down I'll have
time to resume focus on back-config.
I note that one should not expect a completely general solution here,
because there are many common replication environments that preclude the
connectivity required to make such a scheme work. I.e., a common case we
see is with replicas deployed on the opposite side of a firewall from
the master, and access rules set up such that connections can only be
established in one direction between the master and the slaves. In these
scenarios, chaining and floating master configurations would not be
allowed by the firewall policy.
Also, the requirement for all slaves to know of each other makes
configuration a bit more tedious. One of the claimed features for
syncrepl was to avoid the requirement that the provider be configured in
advance with knowledge of each consumer. In a floating master setup,
it's most logical to store/manage all of the consumer knowledge on the
provider and replicate it to the consumers (this is a desired feature of
back-config). Needless to say, this is a very different use case from
the existing syncrepl code, and will require some new config directives
to support it. When working with X.500 knowledge references we found it
was easiest to have all the knowledge references configured identically;
each server would automatically recognize (and ignore) the reference
pointing to itself. This way all of the reference information can be
replicated indiscriminately and identically to all slaves, and each DSA
does the right thing with it. A separate masterID is used to denote
which slot in the list of servers is the current master, and gets
replicated along with the other info.
As for using chaining to accept writes anywhere in the pool - I think
this is the best approach.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support