RE: Crashing database

["Carlos Parada" <carlos-f-parada@ptinovacao.pt>]

Carlos Parada wrote:

> I'm using the openldap 2.3.34 version (I've already used previous ones).

The current 2.3 release is 2.3.40; since you don't point out any
specific issue, I strongly suggest you update to the latest release, so
that we don't risk chasing something that has already been fixed.

> My usage is a bit different than the usual. I have a lot of write
> operations
>
> - tens per second - (adds, deletes) and also a lots of reads.

This is by no means a heavy write load.

[CP] Indeed. And very critical usage.



> I use to have very often a crash in my database. I'm using the bdb
> backend.
>
> Sometimes it is enough to restart my server to corrupt the database (at
> least

"Crash" is rather generic.  Can you be more specific?

[CP] Yes. It starts returning the 80 error code.

Jan  3 23:47:39 linux slapd[14817]: conn=8284139 op=1 SEARCH RESULT tag=101 err=80 nentries=0 text=internal error

When you try to restart to get it right, it doesnt start and suggests you to use db_recovery.



> to not be able to restart it). In other occasions, I corrupt my database
> using
>
> the slapcat command, which I know it is nor recommended, but it is also
> not
>
> disallowed by the application (and I think it was in previous versions).

slapcat is 100% recommended, otherwise it wouldn't be distributed at all.

[CP] Acording to the slapcat manual, it is not recommended while the server is running.



> That buggy behavior should not be normal. I've already search and it
> seems it
>
> is a common problem using  the bdb, many times reported.

If by "bdb" you mean "back-bdb", it's the default backend, it's the
recommended one and it's considered very reliable.  The problem you
indicated is by no means typical, since most of the users do not
experience issues with it within days, months and even years of
continued service.

[CP] Yes. But sometimes this happen. Try to run slapcat to provoke it.

Perhaps I'm too much exigent, but I am very familiar with sql database engines

(like postgres) and there this NEVER happen (it is quite reliable).

Thats doesnt seems the case of openldap.



> My question is: what is really happening? Am I configuring wrongly the
> server,
>
> DBD parameters, or anything else? Or there is a systematic bug not
> solved yet ?
>
> How to solve it?
>
> 
>
> Another secondary issue is the recovery. Most of the times, I'm not able
> to recover
>
> my database either using db_recover or slapd_db_recover. Is there any
> trick for a
>
> more efficient recovery.

With OpenLDAP 2.3 you shouldn't need to run any of those tools, as slapd
(and other slaptools) can detect itself when a recover is needed.  Since
you don't share your slapd and your Berkeley DB configuration, there's
very little to comment about.

[CP] The slapd.conf is the following (includes DB_CONFIG):

database        bdb
#dbnosync
#dbsync          60 10 30
cachesize       500000
dbcachesize     1000000000
suffix          "dc=ptin"
rootdn          "dc=ptin"
rootpw          xxxxxx

directory       /mnt/storage/wifi

index   objectClass             pres,eq
index   uid                     eq,pres
index   dc                      eq,pres


reverse-lookup off
lastmod off
dbnosync

#DB_CONFIG
# one 0.25 GB cache
dbconfig set_cachesize 0 268435456 1

# Data Directory
#set_data_dir db

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

#remove log lines
dbconfig set_flags DB_LOG_AUTOREMOVE

# locks
dbconfig set_lk_max_locks 5000
dbconfig set_lk_max_lockers 5000
dbconfig set_lk_max_objects 5000




As you're not pointing out any specific issue, I suggest you post your
comments to the openldap-software list, until anything indicating a
specific bug surfaces.

[CP]
Thats the reason of my initial '(First of all, sorry for this "generic" thread)' :)

I this that there is a missconfiguration by my side of a bug that I can not

replicate, but happens sometimes.

Many thanks anyway.