[Date Prev][Date Next]
Re: Mirror Mode
Clowser, Jeff (Contractor) wrote:
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".
Right, replication won't break, no corruption.
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.
Sure, that would work.
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.
That's our preferred/recommended usage. As I read somewhere else recently,
"the best solution is not to have problems." Conflict resolution is messy;
it's best to avoid it...
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/