Description of problem:
There seems to be a DB corruption issue with the entry nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,<SUFFIX>.
Typically after a reindexing of a replicated suffix.
Errors log:
[25/Feb/2021:10:34:40.147633966 +0100] - INFO - bdb_db2index - userroot: Finished indexing.
[25/Feb/2021:10:34:42.199441489 +0100] - ERR - _entryrdn_insert_key - Same DN (dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=example,dc=com) is already in the entryrdn file with different ID 133529. Expected ID is 133541.
[25/Feb/2021:10:34:42.202046664 +0100] - ERR - index_addordel_entry - database index operation failed BAD 1023, err=9999 Unknown error 9999
[25/Feb/2021:10:34:42.220902975 +0100] - ERR - NSMMReplicationPlugin - _replica_configure_ruv - Failed to create replica ruv tombstone entry (dc=example,dc=com); LDAP error - 1
[25/Feb/2021:10:35:12.240676559 +0100] - ERR - _entryrdn_insert_key - Same DN (dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=example,dc=com) is already in the entryrdn file with different ID 133529. Expected ID is 133541.
Version-Release number of selected component (if applicable):
$ cat /etc/redhat-release
Red Hat Enterprise Linux release 8.3 (Ootpa)
$
$ grep ^389-ds installed-rpms
389-ds-base-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Tue Jan 5 10:59:38 2021
389-ds-base-debuginfo-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Mon Feb 8 12:25:14 2021
389-ds-base-debugsource-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Mon Feb 8 12:25:13 2021
389-ds-base-legacy-tools-debuginfo-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Mon Feb 8 12:25:15 2021
389-ds-base-libs-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Tue Jan 5 10:59:38 2021
389-ds-base-libs-debuginfo-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Mon Feb 8 12:25:15 2021
389-ds-base-snmp-debuginfo-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Mon Feb 8 12:25:16 2021
$
How reproducible:
At customer site.
Steps to Reproduce:
Triggered by a reindexing of a replicated suffix.
Actual results:
corrupt DB.
$ grep -c "is already in the entryrdn file with different ID" errors* | grep -v :0$
errors:12388
errors.20210208-125224:3
errors.20210216-113244:6401
$
Expected results:
Sane DB.
Additional info:
Similar issue described here:
https://www.spinics.net/linux/fedora/389-users/msg21664.html
I've been able to reproduce this using a CI test that repeatedly makes a few updates, and reindexes the database. It took a few minutes, but I was able to reproduce it. Continuing investigation...
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (redhat-ds:11 bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2022:7929
Description of problem: There seems to be a DB corruption issue with the entry nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,<SUFFIX>. Typically after a reindexing of a replicated suffix. Errors log: [25/Feb/2021:10:34:40.147633966 +0100] - INFO - bdb_db2index - userroot: Finished indexing. [25/Feb/2021:10:34:42.199441489 +0100] - ERR - _entryrdn_insert_key - Same DN (dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=example,dc=com) is already in the entryrdn file with different ID 133529. Expected ID is 133541. [25/Feb/2021:10:34:42.202046664 +0100] - ERR - index_addordel_entry - database index operation failed BAD 1023, err=9999 Unknown error 9999 [25/Feb/2021:10:34:42.220902975 +0100] - ERR - NSMMReplicationPlugin - _replica_configure_ruv - Failed to create replica ruv tombstone entry (dc=example,dc=com); LDAP error - 1 [25/Feb/2021:10:35:12.240676559 +0100] - ERR - _entryrdn_insert_key - Same DN (dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=example,dc=com) is already in the entryrdn file with different ID 133529. Expected ID is 133541. Version-Release number of selected component (if applicable): $ cat /etc/redhat-release Red Hat Enterprise Linux release 8.3 (Ootpa) $ $ grep ^389-ds installed-rpms 389-ds-base-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Tue Jan 5 10:59:38 2021 389-ds-base-debuginfo-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Mon Feb 8 12:25:14 2021 389-ds-base-debugsource-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Mon Feb 8 12:25:13 2021 389-ds-base-legacy-tools-debuginfo-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Mon Feb 8 12:25:15 2021 389-ds-base-libs-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Tue Jan 5 10:59:38 2021 389-ds-base-libs-debuginfo-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Mon Feb 8 12:25:15 2021 389-ds-base-snmp-debuginfo-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 Mon Feb 8 12:25:16 2021 $ How reproducible: At customer site. Steps to Reproduce: Triggered by a reindexing of a replicated suffix. Actual results: corrupt DB. $ grep -c "is already in the entryrdn file with different ID" errors* | grep -v :0$ errors:12388 errors.20210208-125224:3 errors.20210216-113244:6401 $ Expected results: Sane DB. Additional info: Similar issue described here: https://www.spinics.net/linux/fedora/389-users/msg21664.html