我的openldap-2.4.21服务器死机了，因此我检查了系统日志消息并发现报告数据库损坏的日志，我尝试通过发出以下命令来修复：
$ /usr/bin/db4.8_recover -v -h /var/lib/ldap/
Finding last valid log LSN: file: 69 offset 120
Recovery starting from [68][84]
Recovery complete at Mon Nov 7 10:32:54 2011
Maximum transaction ID 80015fb4 Recovery checkpoint [70][28]
之后我尝试启动slapd，但由于 而失败Unacceptable log file。我以前从未遇到过此问题，db4.*_recover总是可以解决问题。我知道的是，ldap 实用程序最近已从 升级db4.7到db4.8。
$ /etc/init.d/slapd start
$ tail -f /var/log/syslog
Nov 7 10:33:08 server slapd[4083]: @(#) $OpenLDAP: slapd 2.4.21 (Jun 2 2011 19:36:19) $#012#011buildd@allspice:/build/buildd/openldap-2.4.21/debian/build/servers/slapd
Nov 7 10:33:08 server slapd[4084]: hdb_db_open: database "dc=example,dc=org": unclean shutdown detected; attempting recovery.
Nov 7 10:33:08 server slapd[4084]: bdb(dc=example,dc=org): Unacceptable log file /var/lib/ldap/log.0000000067: unsupported log version 15
Nov 7 10:33:08 server slapd[4084]: bdb(dc=example,dc=org): Invalid log file: log.0000000067: Invalid argument
Nov 7 10:33:08 server slapd[4084]: bdb(dc=example,dc=org): PANIC: Invalid argument
Nov 7 10:33:08 server slapd[4084]: bdb(dc=example,dc=org): unable to join the environment
Nov 7 10:33:08 server slapd[4084]: hdb_db_open: database "dc=example,dc=org" cannot be recovered, err -30974. Restore from backup!
Nov 7 10:33:08 server slapd[4084]: bdb(dc=example,dc=org): txn_checkpoint interface requires an environment configured for the transaction subsystem
Nov 7 10:33:08 server slapd[4084]: bdb_db_close: database "dc=example,dc=org": txn_checkpoint failed: Invalid argument (22).
Nov 7 10:33:08 server slapd[4084]: backend_startup_one (type=hdb, suffix="dc=example,dc=org"): bi_db_open failed! (-30974)
Nov 7 10:33:08 server slapd[4084]: bdb_db_close: database "dc=example,dc=org": alock_close failed
Nov 7 10:33:08 server slapd[4084]: slapd stopped.
如果我查看有问题的日志文件，它似乎是正确创建的（大小相同且权限正确）
$ ls -lh /var/lib/ldap
-rw-r----- 1 openldap openldap 10M 2011-11-07 08:50 log.0000000065
-rw-r----- 1 openldap openldap 10M 2011-11-07 10:12 log.0000000066
-rw-r----- 1 openldap openldap 10M 2011-11-07 10:17 log.0000000067
-rw-r----- 1 openldap openldap 10M 2011-11-07 10:27 log.0000000068
-rw-r----- 1 openldap openldap 10M 2011-11-07 10:27 log.0000000069
-rw------- 1 openldap openldap 30M 2011-10-28 10:30 mail.bdb
-rw------- 1 openldap openldap 2.5M 2011-10-28 10:30 objectClass.bdb
-rw------- 1 openldap openldap 18M 2011-10-28 10:30 sn.bdb
-rw------- 1 openldap openldap 2.2M 2011-10-28 10:30 uid.bdb
Q1：如何解决不可接受的日志文件问题？
我尝试使用读取日志文件db4.8_printlog -h /var/lib/ldap，到目前为止它已经运行了 1 小时，显示了所有记录的交易。如果它抛出错误，我会更新问题。
此外，当我连续多次运行 db_recovery 实用程序而不重新启动 slapd 时，我发现最后一个有效日志文件每次都会发生变化，这是我没有预料到的
$ /usr/bin/db*.*_recover -v -h /var/lib/ldap/
Finding last valid log LSN: file: 71 offset 120
Recovery starting from [70][84]
Recovery complete at Mon Nov 7 10:41:15 2011
Maximum transaction ID 80015fb4 Recovery checkpoint [72][28]
$ /usr/bin/db*.*_recover -v -h /var/lib/ldap/
Finding last valid log LSN: file: 72 offset 120
Recovery starting from [71][84]
Recovery complete at Mon Nov 7 10:43:31 2011
Maximum transaction ID 80015fb4 Recovery checkpoint [73][28]
问题 2：每次数据库恢复时（完全不使用 slapd）最后一个有效日志文件都会发生变化，这正常吗？
答案1
您最好使用 OpenLDAP 包中附带的实用程序：
$ rpm -ql openldap-servers | grep db_
/usr/sbin/slapd_db_archive
/usr/sbin/slapd_db_checkpoint
/usr/sbin/slapd_db_deadlock
/usr/sbin/slapd_db_dump
/usr/sbin/slapd_db_hotbackup
/usr/sbin/slapd_db_load
/usr/sbin/slapd_db_printlog
/usr/sbin/slapd_db_recover
/usr/sbin/slapd_db_stat
/usr/sbin/slapd_db_upgrade
/usr/sbin/slapd_db_verify
而不是来自db4-utils包：
/usr/bin/db_archive
/usr/bin/db_checkpoint
/usr/bin/db_deadlock
/usr/bin/db_dump
/usr/bin/db_dump185
/usr/bin/db_load
/usr/bin/db_printlog
/usr/bin/db_recover
/usr/bin/db_stat
/usr/bin/db_upgrade
/usr/bin/db_verify
答案2
如果您有足够的时间进行一些基础设施改造，我衷心建议您执行以下操作：
- 停止使用过时的分发包，
- 开始使用来自LDAP 工具箱项目，
- 将数据库格式切换为 MDB：该数据库非常稳定，速度更快，并且只占用基于 BDB 的数据库一半的内存
（2.4.21 和 2.4.39 之间有大量新功能和错误修复，但稳定的 MDB 支持是新版本最重要的功能之一）