openldap service stop cause database corruption

Antonini Gabriele <[email protected]>
Newsgroups gmane.network.openldap.general
Message-ID <81CE9E6CC58F7948868DF703A374EF83AF0EC2B6@pomsx01.intranet.giunti.it>
Hello,
I'm running openldap 2.3.43 on CentOS  5.3 machine (1 Xeon @2.33GHz, 1.5GB RAM).
My LDAP directory contains about 158000 entry (users) loaded from a massive ldif add.
I'm using hdb database and I defined a couple of additional indexes to default configuration.
Very often (not every time) I stop the service and restart I recive this message:

hdb_db_open: unclean shutdown detected; attempting recovery.
hdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.

After I recive this message I can't contact ldap server and I have to run slapd_db_recover (that takes long time) to recover db.

This is a test environment and at this time there is no activity on the server (no read/write operations).

This is DB_CONFIG file content (/var/lib/ldap/DB_CONFIG):

# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.1.2.4 2007/12/18 11:51:46 ghenry Exp $
# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases.
#
# See the Oracle Berkeley DB documentation
#   <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html>
# for detail description of DB_CONFIG syntax and semantics.
#
# Hints can also be found in the OpenLDAP Software FAQ
#       <http://www.openldap.org/faq/index.cgi?file=2>
# in particular:
#   <http://www.openldap.org/faq/index.cgi?file=1075>

# Note: most DB_CONFIG settings will take effect only upon rebuilding
# the DB environment.

# one 0.25 GB cache
# set_cachesize 0 268435456 1
set_cachesize 0 629145600 1

# Data Directory
#set_data_dir db

# Transaction Log settings
set_lg_regionmax 262144
#EXP set_lg_bsize 2097152
#set_lg_dir logs

# Note: special DB_CONFIG flags are no longer needed for "quick"
# slapadd(8) or slapindex(8) access (see their -q option).


I tried to reduce lg_buffer_size to force the server write log file more often to avoid possible "lost transaction" but this isn't working.

Any ideas about the cause of these db corruptios?

Thanks a lot,
Gabriele
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.