On Thu, 2 Dec 2004, Henrique de Moraes Holschuh wrote:
On Thu, 02 Dec 2004, Andreas Hasenack wrote:On Thu, Dec 02, 2004 at 06:48:02PM -0200, Henrique de Moraes Holschuh wrote:wouldn't be appropriate. We could have used bdb, but generally have had lots of problems with bdb so don't entirely trust it...
I don't know of anyone sane that trusts any BDB on the 4.x series.
With cyrus-imapd, that may be so. But don't generalize, BDB is quite robust.
Well, 3.2.9 as packaged by Debian IS robust. I don't have a single misbehaviour (let alone one that caused data loss) reported against it, I think.
Now, for 4.x I do not agree with you. As far as I am concerned, the 4.x series is *not* to be trusted yet. It is not just because of Cyrus (after all, a bug in Cyrus code might cause BDB 4.x to misbehave),
This Cyrus bug has been fixed a long time ago. I've run cyrus with BDB 4.1 or higher for almost two years without any issues.
but also because of all the reports of problems with OpenLDAP.
Well, this is certainly a debatable issue. The latest stable version of OpenLDAP will run only with BDB 4.2.52 or higher. (BDB 4.3.21 is the latest and not without problems) Sure there are folks with horror stories, but there are numerous folks who run OpenLDAP with great success in very busy environments.
As a first example (and just like you said), if you don't get the DB_CONFIG stuff exactly right, you can get anything from lock ups to environment corruption. This is quite easy to hit with OpenLDAP. From what you wrote, I guess subversion will also get hit by this one if DB_CONFIG is not optimal for your dataset.
Second, it is prone to behave badly in non-trivial workloads on non-trivial apps on non-trivial (i.e. not UP) boxes. Which is exactly the kind of thing you have on any big Cyrus or OpenLDAP deployment. I have some hopes that the very latest 4.2 fixes this. I *do* know the others didn't, since I've experienced the crashes myself.
BDB 4.x is a complex piece of software, and it shows.
It's heavily used by openldap and subversion. We, for example, have a
And at least with openldap, it causes a lot of trouble.
subversion repository with about 50Gb of data on a single berkeley database file (version 4.2.52 + 2patches):
Heavy concurrent load on non-UP machines seem to be a much more common cause of trouble with BDB than database size. Index size does couse trouble (when DB_CONFIG is not correctly sized), though.
default values for important settings, data corruption *will* happen.
Indeed.
A correctly configured BDB 4.x environment will behave and perform well. I am yet to corrupt a BDB database to a point where the data is not recoverable.
For those interested, you can find BDB docs at http://www.sleepycat.com/docs/ref/toc.html. As Henrique pointed out, BDB is very complex, but it can also do a very good job.
-- Igor --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
