[Date Prev][Date Next]
Re: MirrorMode behind fail over loadbalancer
<quote who="Chris G. Sellers">
> I think too, the idea is you treat the second master server as a slave
> in practice, meaning you never do updates to it unless the primary
> master is down.
> Effectively, the difference from a Master/Slave setup is that you will
> not have to promote the Slave to a Master and adjust any replication
> agreement settings in the event of a failed server.
> Is that a fair analysis ?
Pretty much and also that the configurations are exactly the same, bar
where the Syncrepl points to and ServerID
> On Jan 22, 2008, at 5:23 PM, Matthew Hardin wrote:
>> Diaa Radwan wrote:
>>> We have two openldap 2.4.7 , configured as MirrorMode, We are
>>> to add load balancer in front of both servers into the production
>>> environment, We don't want too go through conflicts issues as it was
>>> stated before as messy process.
>>> --------- ---------
>>> . . . .
>>> . Srv1 . . Srv2 .
>>> --------- ---------
>>> \ /
>>> ---- ------------
>>> . LoadB .
>>> As per my understanding, the load balancer(failover mode) is
>>> redirecting all traffic to the active server(srv1); if the active
>>> server went down the traffic will be redirected to stand-by
>>> server(srv2). When srv1 goes online again the load balancer will
>>> redirect all trafic to srv1, while srv1 is in progress to get synced
>>> with srv2. The load balancer will not consider the sync process; it
>>> will just redirect the traffic.
>>> it was previously stated on the mailing list that there should be one
>>> write at a time. is there any conflict will occur when server getting
>>> bulk syncing and receiving updates(attribute level)/add requests as
>> Yes, this is a possibility. At Symas we do not advise our customers
>> to immediately switch back to a failed server when it comes back
>> online. Your mirrormode servers should be peers in every sense of
>> the word: They should have the same disk, memory, network, and
>> processor configuration. Therefore it won't matter which server is
>> fielding write requests. When your first server goes offline, your
>> load balancer should switch to the second and continue in that
>> configuration until that one goes offline. Presumably by then you
>> will have gotten your first server back online and it will have
>> synchronized itself. If your second server goes offline, then the
>> load balancer can switch back to the first. The synchronization
>> status can be checked by looking at the operational attribute
>> 'contextCSN' in the root object of the replicated naming context
>> (remember to use '+' or call the attribute name out explicitly when
>> using ldapsearch).
>>> What happen if there attribute-level conflict? how to avoid it?
>>> suggestions are highly welcomed.
>> Best to follow procedure from the previous paragraph. If you
>> absolutely _must_ switch back to the first server as soon as
>> possible, wait until the contextCSN attributes in the mirror pair
>> are equal to one another, or at least reasonably close. Note that in
>> a system with a heavy write load this may not happen long enough to
>> make a clean switch, so 'close' is good enough.
>>> Diaa Radwan
>> Hope this helps,
>> Matthew Hardin
>> Symas Corporation - The LDAP Guys
> Chris G. Sellers | NITLE Technology
> 734.661.2318 | firstname.lastname@example.org
> AIM: imthewherd | GTalk: email@example.com