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

Re: Deletions not propagating in multi-hop syncRepl environment

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.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support