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.
I use the following command to check the ContextCSN on each consumer:
Consumer: 1 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 # # test.com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 # search result search: 2 result: 0 Success
Consumer: 2 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 # # test.com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
So we can see that the two consumers have matching: ContextCSN. 20110313041653.752098Z#000000#000#000000
Lets check the Provider now.
Provider: 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.com dn: 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