Bug 450707 - Upgrades involving old BDB database files
Upgrades involving old BDB database files
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: Release_Notes (Show other bugs)
beta
All Linux
high Severity high
: ---
: ---
Assigned To: Lana Brindley
Kim van der Riet
: Documentation
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-10 11:33 EDT by Kim van der Riet
Modified: 2013-10-23 19:08 EDT (History)
1 user (show)

See Also:
Fixed In Version: 1.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-11 00:25:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kim van der Riet 2008-06-10 11:33:22 EDT
When the broker is started with the store module loaded, the store module will
open the BDB database in the data directory (which is by default whatever the
broker has selected for --data-dir). The BDB files are located under rhm/dat/
within this directory.

In recent testing, it has been observed that if BDB is upgraded, or the store
directory from one version of BDB is used by another version, then the broker
will fail to start. One of the most commonly observed error messages is the
following:

Database handles still open at environment close
Error opening environment (BdbMessageStore.cpp:144): DbEnv::open: Invalid argument

If this should occur, then the following is suggested:

If recovery is not important (i.e. there are no messages or queues that need to
be restored on startup), then simply delete the database and journal (if it
exists) in the store directory. The broker will create a new one when it starts.
This is most easily done with a command such as "rm -rf /var/lib/qpidd/rhm",
where /var/lib/qpidd is the data directory; adjust if you are using a different
path for the data directory.

If recovery is important, then it will be necessary to run the db_recover
utility against the database. This requires that the db4-utils package is
installed; as root, run "yum install db4-utils" to do this.

Note You need to log in before you can comment on or make changes to this bug.