[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