In the following scenario updates can be lost on one server.
1] Assume masters A and B in sync
2] Take a backup from B
3] add some updates on B, check they are replayed to A
4] restore B from backup
changes fro step 3] are now missing on B, they are available an A and in the chnagelog of A, but are not replicated to B
There are (at least) two different scenarios. a) apply the first update after restore on A, a repl session starts and the missing updates are replicated b) apply the first update after restore on B, the missing updates are permanently lost
This might be related to https://fedorahosted.org/389/ticket/369 This ticket tried to fix something similar but in regards to db2ldif/ldif2db
scenario B might somehow be related to https://fedorahosted.org/389/ticket/47986
Preventing a recovered instance to accept direct update could be solution to this problem For example 'referral on update' until the administrator checks that all updates originated by B have been replicated to B
yes, the fix for #369 helps that in scenario a) the changes are not skipped, but there is still the problem why A does not immediately send the missing updates, only if it comes across them "accidently" It also makes the scenario b) more likely
I agree that scenario b) is like #47986 and needs a solution on the consumer side by rejecting updates until in sync
Per triage, push the target milestone to 1.3.6.
Metadata Update from @lkrispen: - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Issue close_status updated to: None - Issue set to the milestone: 1.3.7 backlog (was: 1.3.6.0)
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4 backlog (was: 1.3.7 backlog)
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/1832
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 - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.