[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#4704) accesslog database fails to store contextCSN at shutdown



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