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

Re: Syncrepl vs. replication



Dave Horsfall wrote:

After trying various configurations including some rather long replication chains I finally decided on something which IMHO was rather elegant: each office masters its own suffix (e.g. dc=sg,dc=example,dc=com) whilst carrying slaves for the other zones; a top-level directory hooks them together by handing out referrals back to the local box and to a central backup. Each master replicates to this "replication server" which then replicates back to the other slaves in turn.


This is generally a good solution, especially since the subtrees are geographically distant. I'm not sure I understand what your top-level referral server is accomplishing, but that's OK, not sure I need to understand. ;)

I could do funky things with slapd.conf again, but I suspect I've hit the limitations of the replication protocol. So, would syncRepl be a better choice here? Think of the general case of several servers, mastering several disjoint suffixes, replicating out to several arbitrary slaves (some of which are the aforesaid servers).


The slurpd replication mechanism probably ran out of steam a long time ago. I'm on the verge of completely replacing it with syncrepl in 2.3, as slurpd itself is not viable in the dynamic config environment.

We're running 2.2.26, and will move to 2.3 when it's stable (we don't have the resources to hammer non-STABLE versions).

The usual disclaimers apply, but at the moment the features that existed in 2.2 are far more stable in 2.3. The rough edges in 2.3 are all related to new features; if you don't use them you'll get by just fine. Syncrepl in 2.3 has been working very well.

Back to the general layout, a possible alternative when accesses outside the local suffix are infrequent, is to use back-ldap/back-meta with the proxy cache for all the non-local suffixes. Just a thought. If you can't easily characterize your non-local query traffic as a small set of fixed query templates, it's probably too much trouble.

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