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

Re: backend requirements for syncrepl

The requirements for the syncrepl consumer is different from that for the
provider. For syncrepl consumer, it should be assumed that only the syncrepl
engine updates the database, hence the mechanisms such as trigger and
TIMESTAMP would not be required. The syncrepl engine can then manage
entryCSN in ldap_entries. Perhaps I missed something during this thread
since I was not inline with the ldapsync control issue. I am currently into
the design of a changelog-based operatoin mode of syncrepl. Wondering
whether this would be sufficient for your case.
- Jong-Hyuk

----- Original Message ----- 
From: "Pierangelo Masarati" <ando@sys-net.it>
To: "Jong-Hyuk" <jongchoi@OpenLDAP.org>
Cc: "Kurt D. Zeilenga" <kurt@OpenLDAP.org>; <openldap-devel@OpenLDAP.org>
Sent: Monday, October 04, 2004 3:09 PM
Subject: Re: backend requirements for syncrepl

> Jong-Hyuk wrote:
> >How about having the entryCSN as the max TIMESTAMP values of all the
> >relevant table rows for an entry ? At the next synchronization time, it
> >would be possible to send only those entries having any of the relevant
> >TIMESTAMP values greater than the synchronization cookie.
> >
> >
> Sure.  The point is that these are (RDBMS dependent, BTW) details
> which can be arranged later (depending on whether the overload
> due to reloads is an issue or not, which also depends on the scenario).
> The first issue is to have syncrepl working with a producer that is not
> syncrepl-aware (e.g. doesn't recognize the control).
> p.