[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
>>
>> 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
>