[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP syncrepl woes
--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.
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