[Date Prev][Date Next]
Re: Syncrepl vs. replication
On Tue, 31 May 2005, Howard Chu wrote:
[ Central replication server ]
> 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. ;)
It's just a poor man's "meta" backend (and a local directory, not a
server; poor phrasing on my part):
A search of "dc=example,dc=com" will return a bunch of referrals:
Our custom client will chase those (as will "ldapsearch" with the
undocumented "-C" switch).
> 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.
Noted; thanks. After studying the documentation it looks like it will
support what we want to do, without introducing any surprises.
> 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.
Thanks again; I'll see if I can convince my boss to let me use a beta
product in a production environment :-) Especially if I'm going to be
developing a new back-end...
> 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.
Yes, I've been thinking about that exact thing.
Dave Horsfall DTM VK2KFU email@example.com Ph: +61 2 8425-5508 (d) -5500 (sw)
Corinthian Engineering, Level 1, 401 Pacific Hwy, Artarmon, NSW 2064, Australia