On Wed, Nov 23, 2011 at 10:13 AM, Quanah Gibson-Mount <[email protected]> wrote: > --On Wednesday, November 23, 2011 9:26 AM -0800 Jeffrey Crawford > <[email protected]> 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 >
