Re: poor performance of OpenLDAP vs AD?

[vadim <vadim.tarassov@swissonline.ch>]

Hallo again,

On Thu, 2005-07-14 at 11:19 +0200, Tomasz Chmielewski wrote:
> (...)
> 
> >>  On the other hand, there seems to be
> >>  much overhead concerned with additional data that goes around to keep
> >>  this multimaster state in sync.
> > 
> > 
> > And here is where the argument really falls down - all else is Not 
> > equal, their replication protocol requires a huge amount of metadata to 
> > maintain synchronization for each update.
> 
> Thanks for all your input.
> 
> Perhaps it's my last concern.
> 
> In a multi-master case, we can modify/add/delete entries even when the 
> physical connection between the servers is broken (WAN/VPN down etc.).
> After the connection is back, they will sync according to some alghoritm 
> (mostly timestamps, and if they happen to be equal, then the 
> "supermaster" overwrites all other changes).
> 
> In a master-slave scenario, when the connection to a master is broken, 
> we can't make any updates/modifications on a slave, which sometimes can 
> be a major drawback.
> 
> Or perhaps it's possible to configure OpenLDAP in a way, that we can 
> "temporarily" edit slave database when the connection to the master is 
> broken, and when the connection is back, changes are sent to the master, 
> which in turn decides on what to do with it?

It may be done as simple as you would accept to be it simple. 
1) You "monitor" master. For example, you ask master every 30 sec about
"what LDAP version protocol you support and expect to get 3 back".
2) As soon as you don't get 3 back, you consider you master to be
unavialble, and promote (one of) replica(s) to be a master. It would
mean only to restart one replica with in advance prepared master
configuration, and probably if you have more than one replica, other
replicas to respect new master. It is only a matter of writing and
testing a two shell scripts, where one is doing monitoring in your
crontab. Second is a couple of command executed via SSH. It is all one
day work.

regards, vadim tarassov.
> 
> 
> 
> (...)
> 
> 
-- 
vadim <vadim.tarassov@swissonline.ch>