The BDB environments for the main database and changelog were unified, apparently around version 1.2.7 (cf. http://directory.fedoraproject.org/docs/389ds/howto/howto-move-changelog.html)
As a result, FRI of a consumer no longer works as expected, since the BDB log files in the backup contain references to paths and files related to the changelog on the supplier which are not present (nor should be) on the consumer.
Tested with 1.3.6.14 on CentOS 7.4 x64.
The restoration/initialization fails while making the environment to perform recovery:
[07/May/2018:23:32:12.124143476 -0400] - DEBUG - dblayer_make_private_recovery_env - => [07/May/2018:23:32:12.128069483 -0400] - ERR - libdb - BDB1520 Recovery function for LSN 1 115016 failed on forward pass [07/May/2018:23:32:12.128920802 -0400] - ERR - libdb - BDB0061 PANIC: No such file or directory [07/May/2018:23:32:12.138094423 -0400] - ERR - libdb - BDB1544 process-private: unable to find environment [07/May/2018:23:32:12.139944917 -0400] - ERR - dblayer_make_private_recovery_env - Open error -30973: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery [07/May/2018:23:32:12.140554998 -0400] - DEBUG - dblayer_make_private_recovery_env - <= [07/May/2018:23:32:12.141183592 -0400] - ERR - dblayer_fri_restore - Recovery failed!
Specifically, the failure is triggered when trying to access the changelog directory--in this case, /var/lib/dirsrv/slapd-xyz/changelogdb--which does not exist:
/var/lib/dirsrv/slapd-xyz/changelogdb
open("/var/lib/dirsrv/slapd-xyz/changelogdb/80000031.294afa7b", O_RDWR|O_CREAT, 0600) = -1 ENOENT (No such file or directory)
The replica should be initialized.
Metadata Update from @mreynolds: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None - Issue set to the milestone: 1.4.0
in fact, binary backup in an instance and binary restore in another instance is not supported. We had removed this from documentation some time ago. I let Mark Reynolds comment on this.
You're right @gparente , filesystem initialization no longer works due to libdb's current design. There is no way to add this functionality back - it just won't work.
I will update/remove that wiki page as it's no longer valid.
Closing ticket...
Metadata Update from @mreynolds: - Issue close_status updated to: invalid - Issue status updated to: Closed (was: Open)
ok. Documentation is showing this as supported but all the databases must match exactly in supplier and consumer to make this binary re-init work fine.
Metadata Update from @gparente: - Issue status updated to: Open (was: Closed)
we should be clear what we mean by file system initialization. Just doing the backup and restore of a single backend will not work, but doing a full database backup and restore (including changelog) should work.
Metadata Update from @lkrispen: - Issue close_status updated to: invalid - Issue status updated to: Closed (was: Open)
Why is this reopened? There is nothing we can do on the directory server to change the current behaviour. This is a limitation of libdb.
Yes, if you do a FULL backup/restore of the same replica "type" it could work, but that also includes the changelog, and all other backends. This will not work if you try to do this from a master to a consumer. It should work if you do it from consumer -> consumer, or master -> master, but you can't mix and match it.
Either way this should not be considered a viable way to "initialize" a replica.
Metadata Update from @mreynolds: - Issue status updated to: Open (was: Closed)
I will report a documentation bug in RHEL.
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/2721
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: invalid)
Login to comment on this ticket.