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
On Wed, Nov 23, 2011 at 10:51 AM, Jeffrey Crawford jeffreyc@ucsc.edu wrote:
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.
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
--On Thursday, December 01, 2011 9:38 AM -0800 Jeffrey Crawford jeffreyc@ucsc.edu wrote:
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.
Well, rid can't be zero. rid has to be the rid you selected in the replica for that master connection. Looking at test058, it looks like the correct syntax is to use -c rid=<rid>,csn=0
--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
openldap-technical@openldap.org
-
Jeffrey Crawford -
Quanah Gibson-Mount