On Thursday 06 September 2007 14:41:38 Bruno Lezoray EMSM wrote: > Buchan Milne wrote: > > On Wednesday 05 September 2007 14:14:56 Aaron Richton wrote: > >> http://www.openldap.org/lists/openldap-software/200602/msg00158.html > >> > >> We use this with only slight modifications. Of course, the only time it > >> has ever produced a meaningful notification has been for a few minutes > >> following a fresh server install as changes made since the last slapcat > >> replicate in. (And since that's an expected condition, it's of minimal > >> interest to me on Nagios.) > >> > >> I'll note that all of our syncrepl failures (which are zero as of late; > >> run 2.3.38!) were much more insidious bugs that updated contextCSN > >> because "they thought they worked." > >> > >> On Wed, 5 Sep 2007, Bruno Lezoray EMSM wrote: > >>> Hi all, > >>> > >>> few months ago, i developed script to monitor slurpd replication, by > >>> checking replication logs. > >>> Now, we want to implement SyncRepl replication, and it looks more > >>> complex to know a status of the replication. > >>> Is someone already developed a tool to do that ? > >>> > >>> My first idea is to compare the contextCSN of the suffix entry between > >>> the master and the slave. > >>> I don't know if there is some specific logs that indicate the > >>> replication is broken. > > > > Here is mine, which I use with Hobbit, but which can also be used > > standalone (with name/IP of servers as arguments): > > > > http://staff.telkomsa.net/~bgmilne/bb-openldap.pl > > > > It also does performance monitoring (e.g. graphs of searches, binds, > > operations etc.) in conjunction with Hobbit. It needs no configuration > > (finds all databases with syncrepl, and the updateref for the database, > > from the contents of the monitor backend), but requires (at present) > > anonymous access to cn=monitor. > > > > What it does pick up for me is when replication is interrupted on servers > > separated by a firewall (which I have started observing again, now that > > we do actually have some slaves on a different network). > > > > > > Regards, > > Buchan > > Hi Buchan, > > i'm trying to test your script but, it didn't found entries for the query: > # Get databases that have a master > $ldap_message = $ldap{$slave}->search( > base => $monitor, > scope => 'sub', > filter => > '(&(namingContexts=*)(MonitorUpdateRef=*))', > attrs => [ 'monitorupdateref', > 'namingContexts' ] > ); > And i have the following replication configuration > syncrepl rid=2 > provider=ldap://10.1.1.69:389 > type=refreshOnly > #type=refreshAndPersist > interval=00:00:05:00 > searchbase="o=test" > filter="(objectClass=*)" > scope=sub > #attrs="cn,sn,ou,telephoneNumber,title,l" > schemachecking=on > bindmethod=simple > binddn="cn=root DN, o=test" > credentials=******** > > What do you think ?
My first guess would be you don't have back-monitor configured. Add: moduleload back-monitor.la database monitor access to * by * read before your first database (or something similar) in slapd.conf and restart. Or, try this ldapsearch, see what you get back: $ ldapsearch -LLL -x -h <server> -b cn=monitor '(&(namingContexts=*) (MonitorUpdateRef=*))' monitorupdateref namingContexts > Is it dependent of the replication type (refreshOnly > and refreshAndPersist) ? No. Regards, Buchan
