[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Bug in replication (ITS#1089)

I found that this was a problem with the Berkeley DB-Libraries shipped
with RedHat6.2.

A self compiled Berkeley DB version 2.7.7 works. It was a bit of toying
around to get OpenLDAP to compile with a non-standard (eg. /usr/lib or /lib)
location of the libraries (I had to insert -L/opt/BerkeleyDB/lib and
-I/opt/BerkeleyDB/include into top.mk) - please take this as a
suggestion to provide a switch into the autoconf script!

Anyway, since using this version, OpenLDAP did not show the described
behaviour. This was no replication bug BTW, since the master sometimes
denied deletes/inserts in quick succession, too. Again, no such problems
since using the new DB2-Library.

Thanks anyway,


---- SNIP

Full_Name: Heinz Ekker
Version: 1.2.11
OS: RedHat Linux 6.2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (

We use a heavy loaded directory for authentication purposes. Changes are
made to
a master and the data is replicated to (at the moment) two slaves.

One slave, which is under heavy load, shows strange behaviour:
When one entry is inserted and deleted in a short interval, the insert
although the delete succeeded. The entry in the Reject-Log is 'already
when turning on debugging, we see 'id [num] already in cache'. This does
happen regularly or with any recognizable pattern. Approximately one of
hundred entries failes thusly.

It seems that deletions are synchronized with the backend (we use LDBM),
but not
with the in-memory cache. Or perhaps this is a thread synchronisation

Our cachesize is increased to:
dbcachesize 52428800
cachesize 100000
Although with much lower values, this does happen too. Same whether
'dbcachenowsync' is specified or not.