Hi Reinhard,
That was an unfortunate... I was hoping you were using a newer
version. :) You hit this bug.
Bug 472131
- dbverify: when a duplicate is
large enough to have internal page(s), dbverify issues bogus
out-of-order key errors
The bug was fixed by Sleepycat on db4.8. And we ported the fix back
to 4.3, but no chance to do so to 4.2. So, we cannot use dbverify
to check if the index file is healthy or not... Could it be
possible to reindex the ancestorid index and see if the error goes
away? (Or you could reinitialize the consumer? That would be the
cleanest)
Thanks,
--noriko
Reinhard Nappert wrote:
Hi Noriko,
I run it on a CentOS
4.4 box (Linux 2.6.24). I use the db 4.2 libs with all the
patches.
Oh, yes dbverify does
complain a lot. I see for all of the db files messages like:
[20/May/2011:11:03:05
-0400] DB verify - verify failed(-30976):
/var/lib/dirsrv/slapd-ID/db/userRoot/cn.db4
[20/May/2011:11:03:06 -0400] - libdb: Page 5: out-of-order
key at entry 2
[20/May/2011:11:03:06 -0400] - libdb: Page 5: out-of-order
key at entry 5
[20/May/2011:11:03:06 -0400] - libdb: Page 5: out-of-order
key at entry 8
[20/May/2011:11:03:06 -0400] - libdb: Page 5: out-of-order
key at entry 10
[20/May/2011:11:03:06 -0400] - libdb: Page 5: out-of-order
key at entry 13
[20/May/2011:11:03:06 -0400] - libdb: Page 5: out-of-order
key at entry 16
[20/May/2011:11:03:06 -0400] - libdb: Page 5: out-of-order
key at entry 19
[20/May/2011:11:03:06 -0400] - libdb: Page 5: out-of-order
key at entry 21
[20/May/2011:11:03:07 -0400] DB verify - verify
failed(-30976):
/var/lib/dirsrv/slapd-ID/db/userRoot/parentid.db4
DB verify: Passed
This said, I guess I should re-index the entire db. Any idea, why this is happening?
Right now, I have a 2 MMR
setup, where both masters also have a replication
agreement to a third box, which is a dedicated consumer.
I do run tests, where I perform simultaneously adds and
deletes (not on the same object) on all three boxes. I
just want to verify how replication behaves in 1.2.8.
-Reinhard
Hi Reinhard,
Could you tell me the OS version and Berkeley DB version (rpm -q
db4)?
Could you run "/usr/lib[64]/dirsrv/slapd-ID/dbverify"? Does it
complain anything? Especially, the ancestorid index? If it does,
you may want to re-create the corrupted index...
--noriko
Reinhard Nappert wrote:
Noriko,
I observed one more
item, which does not bother me right now, but you may want
to see:
I am not sure why
and how it happened, but I see the following message on
the supplier:
[18/May/2011:13:59:50
-0400] NSMMReplicationPlugin - agmt="cn=supplier2consumer"
(consumer:389): Consumer failed to replay change (uniqueid
aea3731d-808711e0-83d5fdc8-f32b8f3c, CSN
4dd4085b004800040000): Operations error. Will retry later.
And I see the following on the
consumer:
[18/May/2011:13:59:29 -0400] -
idl_new.c BAD 22, err=-30988 DB_PAGE_NOTFOUND: Requested
page not found
[18/May/2011:13:59:29 -0400] - ancestorid BAD 13120,
err=-30988 DB_PAGE_NOTFOUND: Requested page not found
Any idea, what happened there....
Thanks,
-Reinhard
Hi Reinhard,
Reinhard Nappert wrote:
Hi Noriko,
I have to correct
myself. The box which had the import issue was on a
1.2.7.5 system. The other box was running 1.2.8.2.
So, it looks like
you have fixed the issue with 1.2.8.2.
*relieved* Thanks for testing it on 1.2.8.2!
--noriko
Thanks,
-Reinhard
1.2.8.2
-Reinhard
It looks to me you have hit this bug... Which version of
389-ds-base you are running?
Bug 684996 - Exported tombstone
cannot be imported correctly.
The patch should be in the version 1.2.8.2.
Thanks,
--noriko
On 05/17/2011 11:03 AM, Reinhard Nappert wrote:
Hi,
I have seen the following:
I set 2 systems up in MMR.
Replication worked. For some reason, I needed to take
one of the boxes out of the replication and disabled
replication. Later on, I enabled it again and created
the shadowing agreement to the other box. Now, I saw
the following errors during the import of the db:
[17/May/2011:11:46:04
-0400] NSMMReplicationPlugin -
multimaster_be_state_change
: replica o=base is going offline; disabling
replication
[17/May/2011:11:46:07 -0400] - WARNING: Import is
running with nsslapd-db-privat
e-import-mem on; No other process is allowed to access
the database
[17/May/2011:11:46:08 -0400] - import userRoot:
WARNING: Skipping entry "nsuniqu
eid=06869502-7fe011e0-8f589300-7e7b2163,ou=sample,o=base"
which has no parent,
ending at line 0 of file
"(bulk import)"
[17/May/2011:11:46:08 -0400] - import userRoot:
WARNING: bad entry: ID 453
.....
Any idea, what is going on
there?
Thanks,
-Reinhard
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
|
