[Date Prev][Date Next]
Re: Dealing with BDB Crash
When I recently built openldap 2.4.23, I first tried using whatever 5.x version was the latest on oracle's site.
I do not remember the specifics, but i had problems trying to build openldap with that version of bdb.
I then noticed this in the openldap README file:
BDB and HDB backends require Oracle Berkeley DB 4.4, 4.5,
4.6, 4.7, or 4.8. It is highly recommended to apply the
patches from Oracle for a given release.
I assumed that meant 5.x wasn't supported, built 4.8.latest, and went on with life.
Anyway, if 5.x IS supported it would be great to update that README file for the next openldap release.
On Mar 31, 2011, at 8:54 AM, Aaron Richton wrote:
> On Wed, 30 Mar 2011, Mark wrote:
>> What is 'the appropriate BerkeleyDB library'? Are you referring to a specific version? I have a new OpenLDAP installation I've built with OpenLDAP 2.4.25 & BDB 4.8.30 and have
>> been testing in a 4-way multi-master setup. Should I take the plunge to BDB 5.1.25?
> This changes a bit with time; the experience of the community is occasionally shared on openldap-technical and/or openldap-devel. Keep in mind that not all BerkeleyDB<>OpenLDAP combinations are compatible (I'm noting an unfortunate recent spate of 2.3.43 users recently, for example) so that obviously must color the decision as well.
> As some rules of thumb based on experience:
> * if Oracle releases an official patch, that patch is almost certainly required --- especially if that's the version you've chosen already
> * any version that is pulled from the official download site is to be avoided/uninstalled as soon as practical
> * as with any software, allowing some lab and early adopter/new installation soak time is important
> To take a practical/today's example, 5.1.25 was announced on February 3. If I was on 5.1.19 I'd have moved to it already. However, not being on 5.1, I'd question whether two months of soak is enough versus the generally positive reputation of 4.8.30. Of course, there's no one answer; different organizations have different risk tolerance/patch policy/etc. It's also worth considering your resources/deployment model. Decisions in a syncrepl multimaster environment, where a server should be able to be shot with no user-visible issue, may not be the same as in a classic provider-consumer model.
Dan Pritts, Sr. Systems Engineer
office: +1-734-352-4953 | mobile: +1-734-834-7224