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

Re: syncrepl ramblings again

Jong-Hyuk wrote:

I'd also like to see syncrepl consumer extended to support other content
synchronization methods than LDAPsync so that slapd(8) can be a slave
of most any LDAP server. For instance, it would be great if one could
setup a consumer to use simple LDAP searches (using time stamps to


minimize


traffic) to suck data of some non-LDAPsync provider)... or suck entries
out of a changelog... or whatever.



Assuming that entryCSN and entryUUID are supported by an LDAP server,
a possible approach to generic slapd sync consumer is:

(1) Search for (&(original filter)(entryCSN<clientCookie)) asking only
entryUUID and entryCSN attributes
(2) Delete replica entries not returned by (1)
(3) Search for (&(original
filter)(entryCSN>clientCookie)(entryCSN=<maxCSN(1))
     asking replicated attributes + entryUUID + entryCSN,
     where maxCSN(1) is the maximum entryCSN returned in step (1)
(4) Update clientCookie to maxCSN(1)

As a result, replica is synchronized to the point maxCSN(1)

This in fact emulates the present mode LDAPsync operation without LDAPsync
support in the provider side.

Sounds good to me, except step 3 with maxCSN makes no sense to me. Step 1 must of course be
(&(original filter)(entryCSN<=clientCookie))

and step 3 we'd like to use '>' but LDAP only allows '>=' so
  (&(original filter)(entryCSN>=clientCookie))

As for syncrepl itself: from seeing all the traffic during the startup of a consumer, it would be nice to avoid step 1. What was the motivation for not keeping tombstones around? It seems a small price to pay, compared to the traffic overhead every time a consumer starts up.
--

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