8:23 a.m.
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
9:39 a.m.
New subject: Replication issue
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
11:15 p.m.
New subject: Replication issue
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 ...
8:11 a.m.
New subject: Replication issue
--On Tuesday, September 09, 2008 9:39 AM -0700 Govind c <govindo(a)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
8:34 a.m.
New subject: Replication issue
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(a)staff.telkomsa.net> wrote:
From: Buchan Milne <bgmilne(a)staff.telkomsa.net>
Subject: Re: Replication issue
To: openldap-technical(a)openldap.org, govindo(a)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 ...
9:05 a.m.
New subject: Replication issue
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
10:54 a.m.
New subject: Replication issue
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(a)staff.telkomsa.net> wrote:
From: Buchan Milne <bgmilne(a)staff.telkomsa.net>
Subject: Re: Replication issue
To: govindo(a)yahoo.com
Cc: openldap-technical(a)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 * 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
4877
days inactive
4912
days old
openldap-technical@openldap.org
6 comments
3 participants
participants (3)
-
Buchan Milne -
Govind c -
Quanah Gibson-Mount