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

Re: OpenLDAP syncrepl woes

On Wed, Nov 23, 2011 at 10:13 AM, Quanah Gibson-Mount <quanah@zimbra.com> wrote:
> --On Wednesday, November 23, 2011 9:26 AM -0800 Jeffrey Crawford
> <jeffreyc@ucsc.edu> wrote:
>> read that already:
>> my original question was the following:
>> Granted the above issues might be explained away in that we don't yet
>> have enough ram on the machines yet, however it does seem to present
>> us with a problem when we notice the discrepancy, how do we during run
>> time re-sync the data from the provider server? I have tried the slapd
>> -c rid=2,csn=20111114000000.000000Z but that doesn't seem to do any
>> good. (I've tried several different values of csn=0
>> csn=20111114000000.000000Z#000000#000#000000 etc. to no avail)
> Regardless of RAM limitations, you should never have an inconsistent
> database.  However, so far, the only replication mechanism I've seen
> guarantee this is delta-syncrepl.  This may be better in the upcoming
> OpenLDAP 2.4.27 for syncrepl.
> If you read the slapd man page for the -c option, it is quite clear:
> Use only the rid part to force a full reload.

Humm that didn't seem to work. I'm rebuilding so I'll give that another try.

>> from man slapadd
>>       Your  slapd(8) should not be running when you do this to ensure
>> consis-        tency of the database.
>> So how can I have slapd run, respond to what data it has currently yet
>> understand that it will update all it's data with the source provider
>> updating, adding, removing entries as necessary without removing the
>> database first?
> I don't understand why you would want slapd to respond with completely bogus
> data to any clients doing queries.  If you're going to force reload the
> replica anyway, it makes much more sense to use slapadd from the master
> rather than trying to do it via syncrepl, which can take numerous amounts of
> time longer than doing it via slapadd, and during that entire time period,
> you have the possibility of sending out significantly erroneous data.
> --Quanah
> --
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration