I have a single provider and a single consumer, both quite lightly loaded serving a few hundred clients between them for nss_ldap.
I've been trying to monitor the replication state by comparing contextCSN on both systems, but I'm finding that on the consumer contextCSN is more often than not older than the most recent entryCSN value.
I read contextCSN as so:
ldapsearch -H ldap://ldapserver1.company.org -LLL -x -s base -b dc=company,dc=org contextCSN
contextCSN: 20110715120001.914244Z#000000#000#000000
ldapsearch -H ldap://ldapserver2.company.org -LLL -x -s base -b dc=company,dc=org contextCSN
contextCSN: 20110715085237.656585Z#000000#000#000000
Looking at the values of entryCSN for ldapserver2 (the consumer):
ldapsearch + | grep entryCSN | sort -u
... entryCSN: 20110714154009.500299Z#000000#000#000000 entryCSN: 20110715085237.656585Z#000000#000#000000 entryCSN: 20110715120001.914244Z#000000#000#000000
It can be seen that the most recent entryCSN matches the contextCSN of the provider, but its own contextCSN is an entry behind (often its two or three entries old).
The replication is up to date, but contextCSN on the consumer doesn't seem to be getting updated in all circumstances.
The consumer is replicating using syncrepl refreshAndPersist. Here's the syncrepl configuration for the consumer:
syncrepl rid=001 provider=ldap://ldapserver1.company.org type=refreshAndPersist interval=00:00:05:00 retry="60 +" searchbase="dc=company,dc=org" sizelimit=unlimited timelimit=unlimited binddn="cn=replication,ou=special users,dc=company,dc=org" bindmethod=simple credentials=password schemachecking=off starttls=critical
I'm also using the memberOf overlay.
I see in the list archives that this has been reported before, but I can't find a bug report to go with it: http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/201103/msg00117.html
I'm using OpenLDAP 2.4.12 on 64-bit openSUSE 11.1. I haven't been able to find time to set up a test environment with the latest OpenLDAP to see if the problem exists there. Has anybody else seen this behaviour in the latest OpenLDAP?
My current workaround to monitor replication status is to modify a record created for the purpose and verify that the consumer has picked it up.