[Date Prev][Date Next]
Re: How to detect a corrupt database?
On Wednesday, 5 August 2009 12:40:31 Jordi Espasa Clofent wrote:
> > If your disks are working and haven't run out of space, database
> > corruption pretty much never happens. You probably should describe the
> > situation that leads you to believe there was a corruption. You should
> > also list the versions of software in use.
> I've three OpenLDAP (one provider, two consumers) as central account
> server (implementing also sudo overlay).
> xen-ldap01:/# dpkg -l | grep slapd && uname -a && cat /etc/debian_version
> ii slapd 2.4.11-1 OpenLDAP
> server (slapd)
> Linux xen-ldap01 2.6.18-6-xen-amd64 #1 SMP Wed Oct 15 11:49:51 UTC 2008
> x86_64 GNU/Linux
Is BDB supposed to work under Debian Xen ?
> Some concrete users (3 of 35) get errors when they try to login; only
> them, the others alwasy can login without problem.
> The 3 OpenLDAP server are balanced, so I can reduce the problem. After
> some test, it was clear that the "problem" remains in xen-ldap03 (one of
> the two consumers).
But, it is entirely possible, if you were using ppolicy, that the affected
users were locked out on this slave. How did you verify that they weren't?
> Really I don't know if the ddbb was corrupted or not,
If the database was corrupt, slapd wouldn't start. If it was slightly corrupt,
slapd would have recovered it at start. So, I think you should not refer to
this as corruption.
> but when I did:
> $ /etc/init.d/slapd stop
> $ cd /var/lib/openldap/ && rm *
> $ /etc/init.d/slapd start
But, nothing indicates that it was corrupt. DId you do an export (with
slapcat) and compare it to the other servers? Note that some differences can be
valid, such as pwd* attributes, as password policy state is not replicated
from consumers to providers ....
> the problem disappears. So, I tend to think the problem was some record
> in ddbdd.
> Maybe I'm wrong.
> >> * ¿How I can detect a corrupt database?
> > slapd will detect unclean shutdowns automatically, and automatically
> > recover from them.
> Great. ¿It is showed with normal debug level (256)?
> >> * ¿Is there any tool/command to check the ddbb health (DBD4)?
> > slaptest will tell you if there was an unclean shutdown.
> >> * ¿What can I do if the corrupted database is the provider database?
> > Restore from a backup.
> Yep. I've done a simple cronjob based on slapcat tool.
I don't see that this will do anything to prevent the problem which was most
likely the cause ... (users locked out on one slave, not database corruption).