User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050606
Dave Horsfall wrote:
So assuming that is indeed a cascaded replication (I'm
having trouble in visualising the config) I wonder why the test
works, but fails in real life?
Probably irrelevant (to us) now, as I pointed out to Quanah.
Mostly irrelevant in general, I think. As I've noted a number of times
on this list, the 2.2 syncrepl provider code is dead, for reasons like
this and a few others. The 2.3 code is completely different.
The 2.2 code is embedded in back-bdb; its presence there made the
back-bdb search code too complex to understand and maintain. As "search"
is the primary function of an LDAP server, and the syncrepl code
lengthened the code path of the search operation, it also had a negative
impact on performance regardless of whether you were using syncrepl or
not. (I take some of the blame for that; the syncrepl search code was
originally written in a separate source file, and I consolidated it to
try to eliminate some code duplication. But while eliminating the code
duplication got rid of one maintenance problem, the resulting code was
too dense which became another maintenance problem.)
Also by being directly integrated with the back-bdb code, the syncrepl
code introduced a number of unexpected interactions that typically
resulted in deadlock. And again, the added complexity of the code made
it difficult to unravel the steps leading up to the problems.
The 2.2 code has a number of conflicting design assumptions - it was
intended to support multiple consumer contexts in a single backend, so
that a single backend might pull in data from multiple providers.
However, it was also intended to allow promoting a consumer into a
provider, and a provider only supports a single context. How you choose
which consumer context to promote, and what happens to the other context
records, is unspecified. (And of course, the config mechanisms to set up
multiple consumers in a single backend don't actually work.) The actual
act of promoting or demoting a server requires stopping the server,
modifying a couple database subentries (to turn a consumer context
subentry into a provider context subentry or vice versa) and restarting
the server.
In 2.3 there is only one context per backend, for both consumers and
providers, so no database modification is needed to do promotion or
demotion. You can use back-config to enable/disable the consumer on the
fly, so promotion/demotion can be done instantaneously, via LDAP,
without needing to restart the server.
The 2.3 provider is implemented as an overlay, so it can sit on just
about any backend. (Come to think of it, you could even run it over
back-ldap and turn any vendor's LDAP server into a syncrepl provider.)
Rather than being tightly coupled to the logic of back-bdb, it uses only
generic LDAP functionality to accomplish its work. Instead of having its
functions spread across a number of back-bdb's source files, it's all in
a single place so redundant code is eliminated. And it's all
single-purpose code, so you don't have to decipher both the backend's
coding intent as well as the syncrepl stuff when you want to dig into
its innards.
If you actually want to put syncrepl to use, you should be using
OpenLDAP 2.3. Even if you don't want to use syncrepl, you're still
better off using 2.3 because the code separation means you won't be
paying the performance cost for a feature you're not using.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.comhttp://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support