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

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
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.


Right.

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/