[Fedora-directory-users] Migration from i-planet 52

David Boreham david_list at boreham.org
Mon Dec 18 15:38:57 UTC 2006


Eddie C wrote:

> I ran
> DB ERROR: db_verify: Page 30: out-of-order key at entry 498
> DB ERROR: db_verify: DB->verify: db/o_com/channelcontentowner.db4: 
> DB_VERIFY_BAD: Database verification failed

I'm assuming that you are running the correct version of db_verify (it 
should
perform a version check on the magic number in the region files, so I think
it has to be the right one).

My best guess here is that the process by which a new file is added to
a running DB environment went wrong somehow. The details have changed
a few times over the years and it is just possible that the current FDS
code is not up to date. Potentially the 'problem' would be fixed by
simply stopping and re-starting the server (because the environment
would see all the files closed and then re-opened). I do know that the
process for adding a new file to the environment is correctly followed
in the newer code that deals with individual back-end restore from archive.
Perhaps the online index code is not using the same underlying function.
I haven't taken the time to examine the code though.

The problem I'm thinking about arises when a file that was created
using one db environment (a temporary one, such as is used when building
an index), is opened within another environment, 'bad stuff' can happen
along the lines of what you are seeing. There is state in the file that
references the old environment, which is now stale vs. the new one.
db_verify sees that and barfs. It is possible to avoid this happening
but one has to be careful to make the right calls in the correct order
(the details of which I forget now).

As Rich and Noriko said, if you just re-import after creating the indices
this issue (if it is indeed the one I'm thinking of) will be avoided because
all the files are created at the same time under the same db environment.













More information about the Fedora-directory-users mailing list