Problem with verifying replication state with contextCSN

[Liam Gretton <liam.gretton@leicester.ac.uk>]

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.

-- 
Liam Gretton                                    liam.gretton@le.ac.uk
HPC Architect                                 http://www.le.ac.uk/its
IT Services                                   Tel: +44 (0)116 2522254
University of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom