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

Re: Mirror Mode



Clowser, Jeff (Contractor) wrote:
I have a question about mirror mode, and how it's different from
"multimaster".

In servers like Sun or Red Hat's directory server, a simplified
description of what they term multimaster is that more than one server
can accept writes simultaneously, and it will then propogate all changes
to other servers.  If there is a conflicting change, some form of
conflict resolution logic is implemented.

If I understand Mirror Mode correctly, the major difference is that it
does not contain code for conflict resolution. I.e. both masters are
live, and will accept changes, and try to replicate them to the other
master (the hot standby master does not reject changes when the other
master is the "live" master).  If a conflict occurs, bad things happen.
It depends on some third resource (a load balancer, slapd in proxy mode,
etc) ensuring that all writes go to only one master server at a time,
and that all clients doing writes use that frontend to send writes to.
At the same time, the individual masters don't do anything to enforce
the fact that writes are coming through that load balancer/proxy/etc, so
it's possible to write to both masters concurrently (though not
desirable).

So.. a couple of questions:
1.  Is this understanding a correct one?  Have I missed any key points
(or completely gotten it wrong)?

That's pretty much it.

2.  If so, and I write conflicting changes to both master servers
directly, what happens when they try to sync? (What does it do with the
conflicting changes, does it prevent any future changes from being
replicated or can it "skip" the conflicting change, how do I detect a
conflict to manually fix it, and what do I need to do actually fix it
(can I just resolve the data issue, or do I have to remove something
from a replication queue and how, etc)?)

When MirrorMode was first implemented, the resulting behavior was totally undefined. We told you "Don't Do This" - if you did it anyway, you were on your own.


In the meantime, between when MirrorMode was first implemented and when 2.4 was publicly released, we made further changes to support full multi-master. This includes entry-level conflict resolution in the current version. As such, MirrorMode will be able to tolerate this misuse, but still You Should Not Do This.

3.  I can envision an HA configuration having 2 sites.  At each site I
have a proxy and a master, with one site having the primary master, the
other having a hot standby.  Both proxies direct traffic to the primary
master if it's available, or redirect to the hot standby master if not.
Connection between sites goes down, so one proxy is directing writes to
the primary master, but the other now can't get to the primary, so sends
writes to the hot standby master, thinking it is down.  Assuming this
happens, and NO conflicting modifications are made, when the connection
between sites comes back up, will everything sync up properly so
everything has the same content (if a conflicting change occurs, it
would be covered by the previous point).

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.


Support for attribute-level conflict resolution using delta-syncrepl will appear in a later release.
--
-- 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/