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

Re: Multi-Master Replication



> So, I've gotten MM replication set up and running in test (yes, I know,
> it's experimental.)  In our stress testing (about 50,000 changes to the
> same object talking to the two servers) we managed to wind up in a
> situation that we thought should be impossible: LDAP1 had the last
> update from LDAP2, and LDAP2 had the last update from LDAP1 (They were
> different, and had processed eachother's last change.)
>
> In thinking about it, this is an easy situation to get in:
>     1. Change to LDAP1
>     2. LDAP1 puts it in replog
>     3. Change to LDAP2
>     4. LDAP2 puts it in replog
>     5. slurpd on LDAP1 applies change to LDAP2
>     6. slurpd on LDAP2 applies change to LDAP1
>
> End result: All changes processed, LDAP servers out-of-sync.
>
> I've been wracking my brain trying to figure out an elegant solution to
> this, but I'm at a loss.  Since neither slapd knows about the other
> replication agreement (in a manner of speaking -- they know that they
> have replication agreements, but not who is replicating to them), there
> seems to be no way to serialize the changes such that this situation
> won't happen.
>
> It seems that an external clock or sequence is required.o
>
> Anybody?

Welcome on board.  What about checking the archives before asking
the same ol' question about once a month or so?

November 2002:
http://www.openldap.org/lists/openldap-software/200211/msg00011.html

October 2002:
http://www.openldap.org/lists/openldap-software/200210/msg00328.html

(didn't go back any further, I'll leave it to you as an exercise :)

Pierangelo.
-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it