[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: openldap-server-2.2.29: multimaster support

matthew sporleder wrote:
On 11/21/05, Pierangelo Masarati <ando@sys-net.it> wrote:
This would yield two advantages:
1) reduce by 1 the number of sync propagations in the typical case of no
conflicts
2) make the change immediately available on the server that received the
request

(dam'd: I should have patented this ;)

Sorry, I'd have beaten you to it... :P http://www.openldap.org/lists/openldap-devel/200304/msg00007.html 

If a link failure occurs on one node, the write wouldn't be guaranteed
to exist on all servers, which breaks the Atomicity and Durability
requirement of ACID.  (I think the first step in a multi-master setup
should be ACID compliance, by the way).
I believe a journal and a staging database should be employed to first
record the write, and then test its application.  If those are both
successful on all nodes, then a signal can be given to merge that
information into the production database at an agreed upon time.

That sounds like a distributed transaction manager, like Tuxedo. BerkeleyDB can work with something like that, and we could implement it in slapd without too much trouble. But it's quite different from what most people here are asking for; the overhead for maintaining ACID would drop write throughput to a few operations per second on a moderate sized network.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/