When doing a partial/FRI restoration the database files are copied key-by-key. This is necessary to reset the LSNs so the restored files can merge into the existing DB environment (cf. dblayer_copy_file_resetlsns()) in a recoverable way.
However, dblayer_copy_file_keybykey() does not set the comparison function before calling DB->put(), which means that the restored files will not necessarily be using the proper function.
While all the keys are technically present, indexed searches can still fail to return relevant results because the key order is significant when intersecting the results with the other indices.
How to reproduce:
Backup a database and do a partial restoration. Use dbscan to compare the key order of the backup vs the restored copy.
$ dbscan -r -f <file> 256 512 257 513 258 514 259 515 260 516 261 ...
$ dbscan -r -f <file> 15 16 17 18 19 20 21 22 23 24 25 26 ...
Patch against 1.1.x fedora-ds-base-fribak-resetlsns.patch
Script to verify the restored files vs the backup. bakchk.sh
There is an exception in the dup compare. Probably, we should doc that entryrdn index is not supported in the partial restoration?
a->ai_dup_cmp_fn = entryrdn_compare_dups;
Description by telackey: When doing a partial/FRI restoration the database files are copied key-by-key. This is necessary to reset the LSNs so the restored files can merge into the existing DB environment (cf. dblayer_copy_ file_resetlsns()) in a recoverable way.
Note: The bug was reported and the patch was provided by telackey. (Thank you, Thomas!)
Additional fix by nhosoi: The entryrdn index uses its special dup compare function. The dup compare function is set when the restoring index file is entryrdn.
git patch file (master) 0001-Ticket-47463-IDL-style-can-become-mismatched-during-.patch
Reviewed by Rich (Thank you!!)
Pushed to master: 081ce00..b431452 master -> master commit b431452
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1044212
Patch against 1.2 fds-1.2.11.25-47463.patch
Pushed to 389-ds-base-1.2.11 branch: 75e7607..abe5c89 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit abe5c89
Pushed to 389-ds-base-1.3.0 branch: 893d6df..9ebe2e8 389-ds-base-1.3.0 -> 389-ds-base-1.3.0 commit 9ebe2e80d090537e8f905ef54990bfdec088e267
Pushed to 389-ds-base-1.3.1 branch: 1ebad4b..0e7f59d 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 0e7f59d
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.2.11.26
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/800
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.