Re: OpenLDAP syncrepl woes

[Jeffrey Crawford <jeffreyc@ucsc.edu>]

On Wed, Nov 23, 2011 at 10:51 AM, Jeffrey Crawford <jeffreyc@ucsc.edu> wrote:
> 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.

Finally got to do another test. I tested by changing the permissions
of the replication account permissions and tried restarting with slapd
-c rid=<number> where the number is the id of the rid= definition in
the olcSyncrepl configuration. It didn't seem to work (Note the
permission changes were just what attributes the account could see)

Just for grins I also tried rid=0 and rid by itself. None seemed to
work. I'm guessing I'm just doing something wrong but not sure what it
is.

Jeffrey

>
>>
>>
>>> from man slapadd
>>>
>>> LIMITATIONS
>>>       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
>>