[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Follow up to Corrupt Index files
- To: <openldap-software@OpenLDAP.org>
- Subject: RE: Follow up to Corrupt Index files
- From: "Kevin McEachern" <kmceachern@rim.net>
- Date: Wed, 30 Oct 2002 12:12:49 -0500
- Content-class: urn:content-classes:message
- Thread-index: AcJ/g45joQK3LMAWR2esXBP8f55gnAAruDHgAAFA0eA=
- Thread-topic: Follow up to Corrupt Index files
-----Original Message-----
From: Kevin McEachern
Sent: October 30, 2002 11:49 AM
To: 'Tony Earnshaw'
Subject: RE: Follow up to Corrupt Index files
Thank you for your reply, however some questions still remain unanswered:
> Why in the name of all that is wonderful, if integrity means so much to
> you (which naturally it ought to), don't you run a test DSA with
> whatever it is you want to test?
Data integrity is not the only issue at hand here. A major issue is that we need to be able to DETECT data corruption (which could occur at any time, in production or testing). The only reason I mention this here is because in one of the posts listed in my previous email, it was mentioned that index corruption was the result of an application level error (see: http://www.openldap.org/lists/openldap-software/199911/msg00024.html), and not a database error. So my (restated) questions are: Is this error corrected by using back-bdb instead of back-ldbm, and if not, are there tools (available or in development) that could be used to detect these application level failures.
> Oh - and do try to make backups as the BDB 4 documents
> describe? Not by doing slapcat, but by taking advantage of the
> fine-grained, roll-back logging facilities offered by the latest
> Berkeley technology.
slapcat seems more reasonable to me and (I believe) its how we're planning on doing backups, since this eliminates dependence on a Berkeley database backend, or even OpenLDAP as a directory server.
Thanks again,
Kevin McEachern.