RE: Multimaster further work

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Derek Simkowiak

> > In many cases this comes down to directory design.

> 	Well, yes, but then you don't have conflicting entries for the
> same DN.  You have non-conflicting entries for different DNs,
> and you're
> not even in the discussion anymore  :)

Sometimes the best approach when faced with a hard problem is to take a
different path and avoid facing it in the first place.

I don't see the example of the "boss' stolen laptop, master slapd is down"
being a compelling argument for multimaster replication. I see this as an
extraordinary circumstance which merits a special-case solution. Nothing says
that you can't have multiple copies of your slurpd configuration lying
around. I'd generate a replog entry by hand with the desired modifications
and manually invoke slurpd from an alternate machine to propagate the
revocation to the remaining slaves.

Talk about "5 nines" reliability or somesuch, server up 99.999% of the time.
This translates to 10 minutes of downtime per week. This in itself is pretty
generous, to my mind. I have slapd servers providing SSO/authentication, etc.
to various web sites that have been running for 9-10 months at a time; the
only reason they restart is for software upgrades. There probably isn't even
10 minutes of downtime per *year*. And if it fails, it will assuredly take
less than 10 minutes for failover to the spare server to occur. As such, the
spectre of "single point of failure" also isn't very compelling.

The issue of load-balancing is a red herring. If you have a pool of servers
and you are distributing queries across all of them, the load from write
operations is the same whether you are using single-master or multi-master
replication - the update still has to propagate to every other server. As
such, multi-master replication offers no benefit, while introducing a slew of
potential problems.

>	I strongly disagree.  I think this is an issue that should have
>strong input from the endusers.  Devel lists are somewhat exclusive to
>people who are great at writing code, but not necessarily great at
>identifying endusers' needs.  I think this discussion is best held out "in
>the open", where real-world users of OpenLDAP can make sure their needs
>are being taken into account.

Endusers who have not been around the subject area for a great length of time
tend to misidentify their needs and desired solutions. In any profession, the
percentage of people proficient at thinking critically in that field is a
tiny amount compared to the field as a whole, and as such most enduser input
is typically no better than random noise. I also think it's naive to believe
that developers are not also endusers themselves, and fully cognizant of the
features needed to apply an arbitrary technology to a real world problem.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support