|
So, you are saying that the server would start up when I just
replace the Berkeley Database libraries.
I doubt it, but I will try ......
I think I have to rebuild the source with the new lib. When I
upgrade ds-base with the newly build package, does the server still understand
the db files?
-Reinhard
On 05/24/2011 06:27 AM, Reinhard Nappert wrote:
I do that.
Now, I have two questions:
So, what db version do you
recommend? Hi Reinhard,
Which OS you are
running?
If it's RHEL5 (BDB4.3.29) or RHEL6 (BDB4.7.25), they are
patched. But RHEL4 (BDB4.2.52) was rejected.
More importantly, is there a migration path or do I have to
reload the existing data? I could see issues migrating replicated
environments. There's no data change
needed. The bug was just in the data verification code.
This bug
has more detailed info.
Bug 472131
- dbverify:
when a duplicate is large enough to have internal page(s), dbverify issues bogus
out-of-order key errors
Thanks,
--noriko
Thanks,
-Reinhard
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
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
|
