-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recovered supplier need to reject direct update until it is in sync with the topology #1317
Comments
Comment from nhosoi (@nhosoi) at 2015-03-10 23:41:51 Comments made in the ticket triage: |
Comment from nhosoi (@nhosoi) at 2016-05-13 00:19:24 Per triage, push the target milestone to 1.3.6. |
Comment from nhosoi (@nhosoi) at 2017-02-11 22:49:27 Metadata Update from @nhosoi:
|
Comment from mreynolds (@mreynolds389) at 2017-05-08 22:27:14 Metadata Update from @mreynolds389:
|
Comment from mreynolds (@mreynolds389) at 2020-05-27 16:11:11 Metadata Update from @mreynolds389:
|
Okay, I wrote a test case (for which we just need to add the error checks), and it looks like this: droideck@763ff3c And when I run ds-replcheck after the test, I have the next report. So, the issue seems legit. |
I am also quite sure that the issue is legit.
|
Sounds good! I'll play around with the test a bit more, and I'll create PR later next week. I probably set it as XFail as I'm not exactly sure when we'll work on that... |
Not sure where to comments :( I would suggest a slight change before resuming servers |
Description: Add a test to that checks the situation when a recovered supplier accepts direct updates before being in sync, replica to that supplier and from that supplier is broken. Related: 389ds#1317 Reviewed by: ?
Description: Add a test that checks the situation when a recovered supplier accepts direct updates before being in sync, replica to that supplier and from that supplier is broken. Related: #1317 Reviewed by: @progier389 (Thanks!)
Somehow related to #2035 |
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47986
The problem is that if a recovered supplier accepts direct updates before being in sync, replica to that supplier and from that supplier is broken.
Use case in MMR with two suppliers M1/rid1 and M2/rid2
ldif RUV is : [ rid1_t0, rid2_t1]
T20:
M1 RUV is [rid1_t5, rid2_t6]
M2 RUV is [rid1_t5, rid2_t6]
M1 is recovered from the ldif file
T21:
M1 RUV is [rid1_t0, rid2_t1]
M2 RUV is [rid1_t5, rid2_t6]
T22:
ldapclient send update to M1
M1 RUV is [rid1_t22, rid2_t1]
M2 RUV is [rid1_t5, rid2_t6]
T23
M2 starts a replication session to M1, It will update M2 with updates [rid2_t1..rid2_t6]
M1 RUV is [rid1_t22, rid2_t6]
M2 RUV is [rid1_t5, rid2_t6]
But here replication is broken both ways. M2 does not know rid1_t22 in its CL and can not update M1. After the import, M1 CL has been cleared, so M1 does not know rid1_t5 and can not update M2.
This problem exist with ldif recovery but I think it also exists with backup recovery.
The text was updated successfully, but these errors were encountered: