I've found an interesting issue with delta-sync replication in which the ContextCSN on my consumers, is higher than the contextCSN on my provider. I believe this is causing some other problems with bringing up brand new consumers.
root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <dc=test,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: contextCSN dn: dc=test,dc=com
#
ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com
SASL/EXTERNAL authentication started
SASL username: gidNumber=1001+uidNumber=1010,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <dc=test,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: contextCSN dn: dc=test,dc=com
#
ContextCSN. 20110313041653.752098Z#000000#000#000000
Lets check the Provider now.
root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" ContextCSN dn: dc=test,dc=com
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <dc=test,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: ContextCSN dn: dc=test,dc=com
#
#
test.comdn: dc=test,dc=com
contextCSN: 20110313041653.709140Z#000000#000#000000
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
The providers CSN is smaller:
contextCSN: 20110313041653.709140Z#000000#000#000000
Now I will search cn=accesslog on the Provider:
These are the last two entries:
# 20110313041653.000003Z, accesslog
dn: reqStart=20110313041653.000003Z,cn=accesslog
objectClass: auditAdd
reqStart: 20110313041653.000003Z
reqEnd: 20110313041653.000004Z
reqType: add
reqSession: 34633
reqAuthzID: cn=admin,dc=test,dc=com
reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com
reqResult: 0
reqMod: sn:+ Bank
reqMod: userPassword:+ {SASL}banky
reqMod: uid:+ banky
reqMod: objectClass:+ top
reqMod: objectClass:+ person
reqMod: objectClass:+ shadowAccount
reqMod: structuralObjectClass:+ person
reqMod: cn:+ Bank, Yuri(banky)
reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5
reqMod: creatorsName:+ cn=admin,dc=test,dc=com
reqMod: createTimestamp:+ 20110313041653Z
reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000
reqMod: modifiersName:+ cn=admin,dc=test,dc=com
reqMod: modifyTimestamp:+ 20110313041653Z
# 20110313041653.000006Z, accesslog
dn: reqStart=20110313041653.000006Z,cn=accesslog
objectClass: auditModify
reqStart: 20110313041653.000006Z
reqEnd: 20110313041653.000007Z
reqType: modify
reqSession: 34633
reqAuthzID: cn=admin,dc=test,dc=com
reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com
reqResult: 0
reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com
reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000
reqMod: modifiersName:= cn=admin,dc=test,dc=com
reqMod: modifyTimestamp:= 20110313041653Z
# search result
search: 2
result: 0 Success
As you can see, the provider is not using the latest entryCSN as its ContextCSN, where as the consumer nodes are. Is this intended?
An issue I've experienced with this is when bringing up a brand new consumer. It gets stuck in a loop trying to add that last entry. I'm guessing this has something to do with it using the wrong ConextCSN?
- Yuri