#49662 File System Replica Initialization No Longer Possible
Closed: wontfix 3 years ago Opened 4 years ago by telackey.

Issue Description

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.

Package Version and Platform

Tested with 1.3.6.14 on CentOS 7.4 x64.

Steps to reproduce

  1. Following the FRI documentation, use bak2db to backup the database on the supplier.
  2. Attempt to initialize the replica on a consumer using: bak2db /path/to/bak -n userRoot

Actual results

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:

open("/var/lib/dirsrv/slapd-xyz/changelogdb/80000031.294afa7b", O_RDWR|O_CREAT, 0600) = -1 ENOENT (No such file or directory)

Expected results

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

3 years ago

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)

3 years ago

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)

3 years ago

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)

3 years ago

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)

3 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: invalid
- Issue status updated to: Closed (was: Open)

3 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: invalid)

2 years ago

Login to comment on this ticket.

Metadata