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?
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.
Regards Marten