[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: syncrepl questions



--On Sunday, September 21, 2003 11:00 AM -0700 Quanah Gibson-Mount <quanah@stanford.edu> wrote:

Okay -- Everything seems to have the permissions they need at this point. The replica has root access to its database, full read to the master database. When it connects to the master, it performs the following search:

Sep 21 11:43:25 ldap-dev0.Stanford.EDU slapd[24370]: [ID 848112 local4.debug] conn=13 fd=11 ACCEPT from IP=172.24.14.238:33294 (IP=0.0.0.0:389)
Sep 21 11:43:25 ldap-dev0.Stanford.EDU slapd[24370]: [ID 347666 local4.debug] conn=13 op=0 BIND dn="cn=ldap-dev2,cn=ldap,cn=operational,dc=stanford,dc=edu" method=163
Sep 21 11:43:25 ldap-dev0.Stanford.EDU slapd[24370]: [ID 347666 local4.debug] conn=13 op=1 BIND dn="cn=ldap-dev2,cn=ldap,cn=operational,dc=stanford,dc=edu" method=163
Sep 21 11:43:25 ldap-dev0.Stanford.EDU slapd[24370]: [ID 347666 local4.debug] conn=13 op=2 BIND dn="cn=ldap-dev2,cn=ldap,cn=operational,dc=stanford,dc=edu" method=163
Sep 21 11:43:25 ldap-dev0.Stanford.EDU slapd[24370]: [ID 362707 local4.debug] conn=13 op=0 SEARCH RESULT tag=101 err=0 nentries=0 text=
Sep 21 11:43:25 ldap-dev0.Stanford.EDU slapd[24370]: [ID 951063 local4.debug] conn=13 op=2 BIND authcid="ldap/ldap-dev2.stanford.edu@stanford.edu"
Sep 21 11:43:25 ldap-dev0.Stanford.EDU slapd[24370]: [ID 996101 local4.debug] conn=13 op=2 BIND dn="cn=ldap-dev2,cn=ldap,cn=operational,dc=stanford,dc=edu" mech=GSSAPI ssf=56
Sep 21 11:43:25 ldap-dev0.Stanford.EDU slapd[24370]: [ID 998954 local4.debug] conn=13 op=3 SRCH base="dc=stanford,dc=edu" scope=2 deref=0 filter="(objectClass=*)"
Sep 21 11:43:25 ldap-dev0.Stanford.EDU slapd[24370]: [ID 706578 local4.debug] conn=13 op=3 SRCH attr=* objectClass structuralObjectClass entryCSN

I also see this:
Sep 21 11:44:07 ldap-dev2.Stanford.EDU slapd[9891]: [ID 399881 local4.debug] do_syncrepl : unknown result
Sep 21 11:45:07 ldap-dev2.Stanford.EDU slapd[9891]: [ID 362707 local4.debug] conn=32768 op=0 SEARCH RESULT tag=101 err=0 nentries=0 text=
Sep 21 11:45:53 ldap-dev2.Stanford.EDU slapd[9891]: [ID 399881 local4.debug] do_syncrepl : unknown result

This of course does a full dump of my entire database. Which is a problem -- Why doesn't it simply query for the changes made since it was loaded?

On the master, there is:

# ldapsync, stanford.edu
dn: cn=ldapsync,dc=stanford,dc=edu
structuralObjectClass: subentry
subtreeSpecification: {}
contextCSN: 2003091621:49:05Z#0x0001#0#0000
entryUUID: ead401c4-7d08-1027-8d06-a9c91f571ab3
creatorsName: cn=Manager,dc=stanford,dc=edu
modifiersName: cn=Manager,dc=stanford,dc=edu
createTimestamp: 20030917031521Z
modifyTimestamp: 20030917031521Z
entryCSN: 2003091703:15:21Z#0x00c1#0#0000
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE


On the replica, there is:

# syncrepl2, stanford.edu
dn: cn=syncrepl2,dc=stanford,dc=edu
structuralObjectClass: subentry
syncreplCookie: 2003091618:18:30Z#0x008a#0#0000
subtreeSpecification: {}
entryUUID: aa811dd0-7d96-1027-991e-fd27b6d0edae
creatorsName: cn=Manager,dc=stanford,dc=edu
modifiersName: cn=Manager,dc=stanford,dc=edu
createTimestamp: 20030917201002Z
modifyTimestamp: 20030917201002Z
entryCSN: 2003091720:10:02Z#0x0026#0#0000
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE


My understanding of syncrepl is that it should _only_ do the change that has been made since it the DB was created, not dump the whole DB like it is doing.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html