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 5.0
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).
Really I don't know if the ddbb was corrupted or not, but when I did:
$ /etc/init.d/slapd stop $ cd /var/lib/openldap/ && rm * $ /etc/init.d/slapd start
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.