[Date Prev][Date Next]
Re: OpenLDAP syncrepl woes
On Wed, Nov 23, 2011 at 10:51 AM, Jeffrey Crawford <email@example.com> wrote:
> On Wed, Nov 23, 2011 at 10:13 AM, Quanah Gibson-Mount <firstname.lastname@example.org> wrote:
>> --On Wednesday, November 23, 2011 9:26 AM -0800 Jeffrey Crawford
>> <email@example.com> 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
>>> 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 Gibson-Mount
>> Sr. Member of Technical Staff
>> Zimbra, Inc
>> A Division of VMware, Inc.
>> Zimbra :: the leader in open source messaging and collaboration