[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncrepl questions
At 09:36 AM 9/24/2003, Quanah Gibson-Mount wrote:
>--On Wednesday, September 24, 2003 11:23 AM -0700 "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote:
>
>>Actually, its not a "full" reload, but a update+present refresh
>>that will be common event. They occurs only during refresh and
>>then only when something has changed. So, avoid refresh (use
>>persist mode) and keep the retry interval short (to reduce the
>>chance something changes while disconnected).
>>
>>As Jong noted, history information is needed to use the
>>updates+delete mode (except when there are no deletes, context
>>CSNs can detect that). That should make syncrepl good enough
>>for *most* directory deployments. Syncrepl, even with optimal
>>selection of transfer mode, is likely not good enough for larger
>>directories and/or frequently updated directories. For this,
>>one needs a protocol which transfers attribute level (or even
>>value-level) changes. Syncrel transfers entry-level changes.
>
>I've changed back to persist mode, which is where I started at. If syncrepl is not suited to large scale deployments/deployments with frequent updates,
> does this mean the various ITS's against slurpd will be dropped back into the queue to be fixed, instead of suspended?
First, I note, there is no "queue to be fixed". I did move
a number of ITS from Historic to Incoming, but left them
Suspended. I might later move some of them to Software Bugs.
Of course, whether or not the reports are eventually addressed
has little to do with the categorization or status of the ITS.
Developers contribute per their own desires.
Second, we just started this Syncrepl experiment. I suspect
Syncrepl will prove to be better than the slurpd approach
in almost all deployments. I also suspect that some deployments
will need a far more sophisticated replication engine than either
syncrepl and slurpd provide.
Kurt