[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Monitor the SyncRepl replication status
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