On Wed, Nov 23, 2011 at 10:51 AM, Jeffrey Crawford <jeffr...@ucsc.edu> wrote: > On Wed, Nov 23, 2011 at 10:13 AM, Quanah Gibson-Mount <qua...@zimbra.com> > wrote: >> --On Wednesday, November 23, 2011 9:26 AM -0800 Jeffrey Crawford >> <jeffr...@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 >>