Possible cause
OpenLDAP uses a storage format (BerkeleyDB) which is known to get corrupted if you don’t do a clean shutdown of your machine. So always try to reboot cleanly rather than power-cycling.
Check ownerships
Whatever you do, always make sure that the /var/lib/ldap/* files are owned by ldap:ldap. If this is not the case, the LDAP server will not be able to work. Doing any of the below will most likely set ownership of some files to root:root, so this must be corrected.
Fixing options
The first thing you can try to recover the database is using db_recover. Try:db_recover -h /var/lib/ldap
If this does not work because the database is too corrupt, you can always restore from a backup. Bright by default makes a backup of your LDAP server database every 24 hours for the last week, and also every month. You will find the backups in /var/lib/ldap/backup.
To restore a backup:
# Create a backup of the entire tree, just in case
cp -a /var/lib/ldap{,.backup}
#Shut down OpenLDAP
cmsh -c "device services master; stop ldap"
(Note: just stopping the service in Linux will cause cmd to restart it fairly soon)
#Shut down OpenLDAP for RHEL7-like or SLES12 base distributions:
cmsh -c "device services master; stop slapd"
# Clear out the current database
cd /var/lib/ldap
rm -f __db.* *.bdb alock log.*
#Restore an old backup
module load openldap
zcat /var/lib/ldap/backup/backup-daily-Fri.ldif.gz | slapadd
chown ldap:ldap /var/lib/ldap/*
chown -R root:root /var/lib/ldap/backup
#Start OpenLDAP
cmsh -c "device services master; start ldap"
#Start OpenLDAP for RHEL7-like or SLES12 base distributions:
cmsh -c "device services master; start slapd"Recovery using the failover head
Another option to consider, for head nodes that are in a failover configuration. For example, head1 and head2. If ldap is correct on head2 and corrupt on head1, you can scp /var/lib/ldap/ to head1. Make a backup of the directory of head1 first.