Hi, Is there a way to force the replication between Master and the slave?. The number of objects and entries are the same in both master and slave,however the some fields don`t have the same content (eg : last login time)Wondering if there is way to keep both in sync in terms of content and objects/entries.
Cheers CG
I have a strange problem,the replication between master and slave is functioning well,however I do see difference in number of objects.Why is that?
Master# ldapsearch -x -b 'o=abc.com' '(objectclass=*)' | egrep " numResponses|numEntries" # numResponses: 38861 # numEntries: 38860
Slave# ldapsearch -x -b 'o=abc.com' '(objectclass=*)' | egrep " numResponses|numEntries" # numResponses: 38857 # numEntries: 38856
Cheers CG
On Tuesday 09 September 2008 18:39:56 Govind c wrote:
I have a strange problem,the replication between master and slave is functioning well,however I do see difference in number of objects.Why is that?
Master# ldapsearch -x -b 'o=abc.com' '(objectclass=*)' | egrep " numResponses|numEntries" # numResponses: 38861 # numEntries: 38860
Slave# ldapsearch -x -b 'o=abc.com' '(objectclass=*)' | egrep " numResponses|numEntries" # numResponses: 38857 # numEntries: 38856
Did you compare the contextCSN attributes on the servers when you compared the number of entries ? Comparing the contents is only valid if the servers think they are in sync ...
--On Tuesday, September 09, 2008 9:39 AM -0700 Govind c govindo@yahoo.com wrote:
I have a strange problem,the replication between master and slave is functioning well,however I do see difference in number of objects.Why is that?
Master# ldapsearch -x -b 'o=abc.com' '(objectclass=*)' | egrep " numResponses|numEntries" # numResponses: 38861 # numEntries: 38860
Slave# ldapsearch -x -b 'o=abc.com' '(objectclass=*)' | egrep " numResponses|numEntries" # numResponses: 38857 # numEntries: 38856
Have you done a slapcat of each, and compared the resulting LDIF?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
I don`t find any contextCSN,we are not using the syncrepl instead the replication parameters are configured in slapd.conf.
Master replica uri=ldap://slave:389 binddn="cn=Replicator,o=abc.com" bindmethod=simple credentials=simple replogfile /var/lib/ldap/openldap-master-replog
Slave updatedn "cn=Replicator,o=abc.com" updateref ldap://master:389 access to * by dn="cn=Replicator,o=abc.com" =rw by * read
The ldiff files (from slapcat) are not the same in size on matser and slave.
Cheers CG --- On Wed, 9/10/08, Buchan Milne bgmilne@staff.telkomsa.net wrote:
From: Buchan Milne bgmilne@staff.telkomsa.net Subject: Re: Replication issue To: openldap-technical@openldap.org, govindo@yahoo.com Date: Wednesday, September 10, 2008, 2:15 AM On Tuesday 09 September 2008 18:39:56 Govind c wrote:
I have a strange problem,the replication between
master and slave is
functioning well,however I do see difference in number
of objects.Why is
that?
Master# ldapsearch -x -b 'o=abc.com'
'(objectclass=*)' | egrep "
numResponses|numEntries" # numResponses: 38861 # numEntries: 38860
Slave# ldapsearch -x -b 'o=abc.com'
'(objectclass=*)' | egrep "
numResponses|numEntries" # numResponses: 38857 # numEntries: 38856
Did you compare the contextCSN attributes on the servers when you compared the number of entries ? Comparing the contents is only valid if the servers think they are in sync ...
On Wednesday 10 September 2008 17:34:29 Govind c wrote:
I don`t find any contextCSN,we are not using the syncrepl instead the replication parameters are configured in slapd.conf.
Master replica uri=ldap://slave:389 binddn="cn=Replicator,o=abc.com" bindmethod=simple credentials=simple replogfile /var/lib/ldap/openldap-master-replog
Slave updatedn "cn=Replicator,o=abc.com" updateref ldap://master:389 access to * by dn="cn=Replicator,o=abc.com" =rw by * read
With slurpd, failures can occur, and depending on the reason for the failure, replication will not fix itself. You should either monitor the reject files and the status files sluprd generates, or switch to syncrepl (which will allow you to monitor replication status, and in many failure scenarios replication will catch up).
Regards, Buchan
So the only option to sync... would be to push the slapcat from the master(ldiff file) and load it into the slave.
Cheers Govind
--- On Wed, 9/10/08, Buchan Milne bgmilne@staff.telkomsa.net wrote:
From: Buchan Milne bgmilne@staff.telkomsa.net Subject: Re: Replication issue To: govindo@yahoo.com Cc: openldap-technical@openldap.org Date: Wednesday, September 10, 2008, 12:05 PM On Wednesday 10 September 2008 17:34:29 Govind c wrote:
I don`t find any contextCSN,we are not using the
syncrepl instead the
replication parameters are configured in slapd.conf.
Master replica uri=ldap://slave:389 binddn="cn=Replicator,o=abc.com" bindmethod=simple credentials=simple replogfile /var/lib/ldap/openldap-master-replog
Slave updatedn "cn=Replicator,o=abc.com" updateref ldap://master:389 access to * by dn="cn=Replicator,o=abc.com"
=rw
by * readWith slurpd, failures can occur, and depending on the reason for the failure, replication will not fix itself. You should either monitor the reject files and the status files sluprd generates, or switch to syncrepl (which will allow you to monitor replication status, and in many failure scenarios replication will catch up).
Regards, Buchan
openldap-technical@openldap.org
-
Buchan Milne -
Govind c -
Quanah Gibson-Mount