[Date Prev][Date Next]
Re: slurpd and back-config
Kurt D. Zeilenga wrote:
I note that one aspect of slurpd architecture is that one canTrue. Although one could write additional overlays to do the rewriting
insert a replog rewriting agent between slapd(8) and slurpd(8).
If we move all the provider side into an overlay, we'd lose
I guess that's OK for now, but eventually we need to provide a
dynamically configurable slurpd replacement.
Maybe it is better to simply say that slurpd users cannot
I think we can already handle this right now using a separate slapd
process configured with a syncrepl consumer on a back-ldap database. If
the consumer operates in persist mode then updates from the master will
be propagated in realtime to the remote slave through back-ldap. If the
back-ldap target becomes unreachable, we just have to abandon the
persistent search until the remote comes back online, and then the
syncrepl refresh will bring the remote back up to date without any
replogs or intervention required. There are some retry details that have
to be covered before this will work in the current code, but overall
this should be no problem to work up.
The only real coding effort required here is if we want to condense the
replicator into the main slapd process (and avoid the need to run a
second slapd instance). In that case, we need the functionality of both
the syncrepl provider and consumer in a single module.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support