RE: BDB recovery after power outage

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Luke A. Kanies

> It's quite an assumption on your part that I haven't read any of the
> documentation, when it's pretty obvious that one must read at
> least some
> documentation in order to get OpenLDAP running at all.

You wrote:

>>>Actually, the first one resulted first in a significant outage, since the
>>>database apparently wasn't clean or something (no, I'm not that familiar
>>>with BDB), which caused slapd to conveniently just sit there unable to
>>>open the database and taking 100% of my CPU; it also wouldn't respond to
>>>signals or give any feedback.  I finally figured out that the database had
>>>to be recovered, but said recovery resulted in data loss (and not data
>>>that was incredibly recent, either).

The slapd-bdb(5) manpage specifically talks about a "checkpoint" keyword,
used to guarantee that buffered data is flushed to disk. If you had actually
read the available documentation you would (a) not be unfamiliar with BDB and
(b) not be dealing with lost data.

The reason that slapd was hung on restart is because BerkeleyDB writes its
lock information into its environment files. These files persist past program
restarts and system restarts. If a program using a BDB environment exits
uncleanly, it leaves its lock records in the environment and you must use
db_recover to clean things up. This also is spelled out in the BDB
documentation.

In early versions of OpenLDAP 2.1 we had slapd automatically perform recovery
whenever it started. However, this caused problems if you accidentally
started a second slapd while one was running - the second recovery would wipe
out the environment that the first one was using. Since all of the locking
information is contained inside the BDB environment, there was no locking
mechanism to prevent this occurrence. So now we no longer do automatic
recovery; it's up to you to run db_recover by hand or add it to your server
startup scripts as needed.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support