Re: Bug in replication (ITS#1089)

[Heinz Ekker <hekker@netway.at>]

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,

Heinz

---- SNIP

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


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
fails,
although the delete succeeded. The entry in the Reject-Log is 'already
exists',
when turning on debugging, we see 'id [num] already in cache'. This does
not
happen regularly or with any recognizable pattern. Approximately one of
a
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
problem.

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.