[Date Prev][Date Next]
Re: Bug in replication (ITS#1089)
I found that this was a problem with the Berkeley DB-Libraries shipped
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.
Full_Name: Heinz Ekker
OS: RedHat Linux 6.2
Submission from: (NULL) (18.104.22.168)
We use a heavy loaded directory for authentication purposes. Changes are
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),
with the in-memory cache. Or perhaps this is a thread synchronisation
Our cachesize is increased to:
Although with much lower values, this does happen too. Same whether
'dbcachenowsync' is specified or not.