[Date Prev][Date Next]
Re: Real alternatives to BDB?
Marten Lehmann wrote:
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.
Hm, according to Red Hat, their build of OpenLDAP 2.2 is extremely stable.
Perhaps, since you paid them for RHEL4, you should file a bug report with them
to let them know how wrong they are. They don't listen to us, nor do they give
away Red Hat Network accounts to mere Open Source Developers whose code they
resell, so we can't file bug reports for you.
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?
I have to admit, that I'm not using the latest releases of bdb. But I'm
using and watching bdb for years and I hardly believe, that it has
become stable in the latest release.
4.2.52 (with documented patches) has never failed for me. 4.3 was known to
blow up in many situations. 4.6.21 looks pretty good, there's no reported
problems with it. BDB 4.7 is in the works already. On my last test, 4.7.13
SEGV'd in its deadlock detector, so yeah, I guess their release record is kind
of spotty. But that's also the nature of newer software; as 4.7 is still early
in its release cycle I expect it will improve just as the others did.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/