[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