Hello,
we are currently running openldap 2.2.13 with a bdb-4.2.52 backend as it
comes with RHEL4. We have about 50.000 cn's each having about 5-10
attributes with a length of no longer than 100 characters. So our
dataset is not very big.
We have a lot of concurrent reads since or ldap provides the data for
incoming and pop3/imap servers. But we have only about 100 changes/adds
a day, not more.
Yesterday we had the second bdb problem in our 1 year ldap setup. The
problem is, that we cannot really detect the crash, since ldap queries
just hang, but neither they timeout nor openldap is crashing. We just
notice the mailserver issues and have to track it down to openldap and
bdb. As with last time, we had to shutdown openldap and recover bdb.
Fortunately we have been able to recover the data-directory both times
using dv_recover. But in fact, we want to have a backend, that doesn't
crash twice a year. And as our setup is growing and we want to start
with replication, we want a backend to whom we can trust.
I read through the backend documentation of openldap and berkeley db is
praised as very fast and efficient. Amazing, that berkeleydb is not
called stable anywhere in the documentation. And from my experience, bdb
is not stable. Whenever you here about bdb, you here about it because a
database went corrupt.
bdb is just a key/value database that seems to
work fine as long it is read-only. Different projects, e.g. subversion,
have turned away from bdb and use a different backend.
Often they use SQLite. Since SQLite handles complete table layouts, it
would also be possible to create one table with two columns (key and
value as in bdb). SQLite shall also be transactional.
But why is openldap sticking on bdb? Does bdb have any other important
features the SQLite doesn't have? Benchmark issues? Replication?