[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