Full_Name: Quanah Gibson-Mount Version: 2.3.27 OS: Linux 2.6 kernel URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86)

I recently set up a script to monitor whether or not my replicas are in sync with the master. I've found that since my master shuts down nightly, this triggers a bug in accesslog where it fails to store its current contextCSN at that time. Then, when the master restarts, accesslog creates a new contextCSN that the slaves pick up, but the master's main database (dc=stanford,dc=edu) doesn't. For example:

nagios1:~> /usr/lib/nagios/plugins/check_syncrepl -H ldap-uat1 CRITICAL dc=stanford,dc=edu out of sync 0 weeks 0 days 2:46:12 ahead

nagios1:~> ldapsearch -LLL -Q -h ldap-uat0 -s base -b cn=accesslog contextCSN dn: cn=accesslog contextCSN: 20061008111122Z#000000#00#000000

nagios1:~> ldapsearch -LLL -Q -h ldap-uat1 -s base -b dc=stanford,dc=edu contextCSN dn: dc=stanford,dc=edu contextCSN: 20061008111122Z#000000#00#000000

nagios1:~> ldapsearch -LLL -Q -h ldap-uat0 -s base -b dc=stanford,dc=edu contextCSN dn: dc=stanford,dc=edu contextCSN: 20061008082510Z#000000#00#000000

where ldap-uat0 is my master. You can see the accesslog DB has the new contextCSN, which its pushed out to the slaves, while dc=stanford,dc=edu on the master still has the correct contextCSN.

This happens in my test, uat, and prod environments, and remains this way until the environments receive their first update, after which the CSN's all get sync'd.

--Quanah