Howard Chu wrote:
When a network partition occurs, there are a number of cases where synchronization may still fail. I.e., we don't yet support
attribute-level
conflict resolution, so if multiple changes are made to the same
entry, even
if they are non-conflicting from a logical standpoint, they may not
apply
correctly in the current version.
I should restate this - syncrepl guarantees eventual convergence; when
network
connectivity is restored the two servers will eventually synchronize.
But
because we're doing entry-level resolution with last-writer-wins
semantics,
the end result may not be what you expected.
I take this as: If I update the cn on one server, then update the password on the other, the end result may be that the cn change gets undone/overwritten when the password gets synced, or something similar - as you said, not the results one would expect in a "true" multiple master setup.
In any case, sounds like the servers do at least eventually come to a common state, where everything again matches. Not ideal, I can deal with that, if that's the worse that happens when the "wrong thing" is done like this. What I can't deal with is if the servers don't eventually match, or if they break replication or become corrupt such that I have to do major work to get things "back to normal".
I imagine if we are proxying this through an openldap server in proxy mode, the "real" master server will see writes coming from the IP address of this proxy, and we could tighten up write acl's to only allow writes from these proxy IP's(?) That wouldn't really solve the problem of the 2 datacenters getting disconnected, but would at least mostly prevent anything writing directly to the individual backend masters.
I suppose the *real* solution is to use the multi-mastering capability in 2.4 to keep it in sync, but use it as if it's mirror mode (i.e. all writes to a single master, with the second as a hot standby), with the MM conflict resolution kicking in if needed because someone wrote to the hot standby when they shouldn't have.
- Jeff