[Date Prev][Date Next]
RE: Mirror Mode
>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
>> conflict resolution, so if multiple changes are made to the same
>> if they are non-conflicting from a logical standpoint, they may not
>> correctly in the current version.
>I should restate this - syncrepl guarantees eventual convergence; when
>connectivity is restored the two servers will eventually synchronize.
>because we're doing entry-level resolution with last-writer-wins
>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
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.