我从openldap-2.4.39-8.el6.x86_64升级到2.4.40-12.el6.x86_64 openldap和重新启动服务器后，我得到以下错误。 我正在试图找出如何恢复，因为我没有备份。
586d0afc <<< dnNormalize: <cn=write> 586d0afc backend_startup_one: starting "dc=custsvc,dc=mycompany" 586d0afc bdb_db_open: "dc=custsvc,dc=mycompany" 586d0afc bdb_db_open: database "dc=custsvc,dc=mycompany": dbenv_open(/var/lib/ldap). 586d0afc bdb(dc=custsvc,dc=mycompany): file id2entry.bdb has LSN 1/720219, past end of log at 1/600 586d0afc bdb(dc=custsvc,dc=mycompany): Commonly caused by moving a database from one database environment 586d0afc bdb(dc=custsvc,dc=mycompany): to another without clearing the database LSNs, or by removing all of 586d0afc bdb(dc=custsvc,dc=mycompany): the log files from a database environment 586d0afc bdb(dc=custsvc,dc=mycompany): /var/lib/ldap/id2entry.bdb: unexpected file type or format 586d0afc bdb_db_open: database "dc=custsvc,dc=mycompany": db_open(/var/lib/ldap/id2entry.bdb) failed: Invalid argument (22). 586d0afc ====> bdb_cache_release_all 586d0afc backend_startup_one (type=bdb, suffix="dc=custsvc,dc=mycompany"): bi_db_open failed! (22) 586d0afc slapd shutdown: initiated 586d0afc ====> bdb_cache_release_all 586d0afc bdb_db_close: database "dc=custsvc,dc=mycompany": alock_close failed 586d0afc slapd destroy: freeing system resources. 586d0afc slapd stopped. 所以在环顾networking后，没有find一个db_recover -v -h /var/lib/ldap/的解决scheme，唯一推荐的方法似乎是db_recover -v -h /var/lib/ldap/这不起作用，但我注意到它增加了恢复检查点。
[root@lddev-build-par01 ~]# db_recover -v -h /var/lib/ldap/ Finding last valid log LSN: file: 1 offset 1632 Recovery complete at Wed Jan 4 14:52:26 2017 Maximum transaction ID 0 Recovery checkpoint [1][1632] [root@lddev-build-par01 ~]# db_recover -v -h /var/lib/ldap/ Finding last valid log LSN: file: 1 offset 1724 Recovery complete at Wed Jan 4 14:52:26 2017 Maximum transaction ID 0 Recovery checkpoint [1][1724]
因此，在确定我有非工作数据的备份后，我只是多次运行该命令，直到恢复检查点高于BDB文件认为问题的位置。 我没有真正期待它的工作。
while true; do db_recover -v -h /var/lib/ldap/; done
但它确实:-)
我不想保证没有数据丢失，但由于这是一个开发环境，它不是世界末日，testing套件很快就会发现任何问题。 希望这有助于某人。