[BugFix] Fix the bug in the FE clone scheduling that causes an infinite loop #50561

sevev · 2024-09-02T09:57:05Z

Why I'm doing:

Some VERSION_INCOMPLETE replicas may not be able to be scheduled for clone repair, such as the following scenario:

The partition visible version is 100 because there are some replica version is still 100 and version 101 publish failed.
The ingestion task is continuous and the lastest committed version is 120.
There are two VERSION_INCOMPLETEreplicas, the first replica commit version101and120failed, so the first replica version is100, last failed version is 120. The second replica commit version 102and108failed, so the second replica version is101and the last failed version is108`.
We consider these two replicas are needed to repair because their last failed version are both greater than 0 and we will choose the replica which last failed version is smaller to repair first.
However, we use visible version in clone task because the clone task can only clone the data with visible version. So the second replica version is still 101 and last failed version is 108.
After clone, the second version is still VERSION_INCOMPLETE and we will try to repair again and again which cause the first replica can not repair any more and the the partition visible version is blocked.

What I'm doing:

Try to fix the replica which version is smaller first.

Fixes #issue

What type of PR is this:

Does this PR entail a change in behavior?

Yes, this PR will result in a change in behavior.
No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

Interface/UI changes: syntax, type conversion, expression evaluation, display information
Parameter changes: default values, similar parameters but with different default values
Policy changes: use new policy to replace old one, functionality automatically enabled
Feature removed
Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

I have added test cases for my bug fix or my new feature
This pr needs user documentation (for new or modified features or behaviors)
- I have added documentation for my new feature or new function
This is a backport pr

Bugfix cherry-pick branch check:

…e loop Signed-off-by: sevev <[email protected]>

Signed-off-by: sevev <[email protected]>

sonarcloud · 2024-09-03T10:54:56Z

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

github-actions · 2024-09-03T13:01:41Z

[Java-Extensions Incremental Coverage Report]

✅ pass : 0 / 0 (0%)

github-actions · 2024-09-03T13:02:22Z

[FE Incremental Coverage Report]

✅ pass : 4 / 4 (100.00%)

file detail

	path	covered_line	new_line	coverage	not_covered_line_detail
🔵	com/starrocks/clone/TabletSchedCtx.java	4	4	100.00%	[]

github-actions · 2024-09-03T13:02:29Z

[BE Incremental Coverage Report]

✅ pass : 0 / 0 (0%)

github-actions · 2024-09-06T02:22:34Z

@Mergifyio backport branch-3.3

github-actions · 2024-09-06T02:22:35Z

@Mergifyio backport branch-3.2

github-actions · 2024-09-06T02:22:37Z

@Mergifyio backport branch-3.1

mergify · 2024-09-06T02:22:37Z

backport branch-3.3

✅ Backports have been created

#50778 [BugFix] Fix the bug in the FE clone scheduling that causes an infinite loop (backport #50561) has been created for branch branch-3.3

mergify · 2024-09-06T02:22:43Z

backport branch-3.2

✅ Backports have been created

#50779 [BugFix] Fix the bug in the FE clone scheduling that causes an infinite loop (backport #50561) has been created for branch branch-3.2

mergify · 2024-09-06T02:22:44Z

backport branch-3.1

✅ Backports have been created

#50780 [BugFix] Fix the bug in the FE clone scheduling that causes an infinite loop (backport #50561) has been created for branch branch-3.1

…te loop (#50561) ## Why I'm doing: Some `VERSION_INCOMPLETE` replicas may not be able to be scheduled for clone repair, such as the following scenario: 1. The partition visible version is `100` because there are some replica version is still `100` and version `101` publish failed. 2. The ingestion task is continuous and the lastest committed version is `120`. 3. There are two VERSION_INCOMPLETE` replicas, the first replica commit version `101` and `120` failed, so the first replica version is `100`, last failed version is `120`. The second replica commit version `102` and `108` failed, so the second replica version is `101` and the last failed version is `108`. 5. We consider these two replicas are needed to repair because their `last failed version` are both greater than 0 and we will choose the replica which `last failed version` is smaller to repair first. 6. However, we use visible version in clone task because the clone task can only clone the data with visible version. So the second replica version is still `101` and last failed version is `108`. 7. After clone, the second version is still `VERSION_INCOMPLETE` and we will try to repair again and again which cause the first replica can not repair any more and the the partition visible version is blocked. ## What I'm doing: Try to fix the replica which version is smaller first. Signed-off-by: sevev <[email protected]> (cherry picked from commit 19b833f)

…te loop (backport #50561) (#50780) Co-authored-by: zhangqiang <[email protected]>

sevev · 2024-09-06T05:57:15Z

@mergify backport branch-2.5

mergify · 2024-09-06T05:57:23Z

backport branch-2.5

✅ Backports have been created

#50787 [BugFix] Fix the bug in the FE clone scheduling that causes an infinite loop (backport #50561) has been created for branch branch-2.5

…te loop (#50561) ## Why I'm doing: Some `VERSION_INCOMPLETE` replicas may not be able to be scheduled for clone repair, such as the following scenario: 1. The partition visible version is `100` because there are some replica version is still `100` and version `101` publish failed. 2. The ingestion task is continuous and the lastest committed version is `120`. 3. There are two VERSION_INCOMPLETE` replicas, the first replica commit version `101` and `120` failed, so the first replica version is `100`, last failed version is `120`. The second replica commit version `102` and `108` failed, so the second replica version is `101` and the last failed version is `108`. 5. We consider these two replicas are needed to repair because their `last failed version` are both greater than 0 and we will choose the replica which `last failed version` is smaller to repair first. 6. However, we use visible version in clone task because the clone task can only clone the data with visible version. So the second replica version is still `101` and last failed version is `108`. 7. After clone, the second version is still `VERSION_INCOMPLETE` and we will try to repair again and again which cause the first replica can not repair any more and the the partition visible version is blocked. ## What I'm doing: Try to fix the replica which version is smaller first. Signed-off-by: sevev <[email protected]> (cherry picked from commit 19b833f)

…te loop (backport #50561) (#50778) Co-authored-by: zhangqiang <[email protected]>

…te loop (backport StarRocks#50561) (StarRocks#50778) Co-authored-by: zhangqiang <[email protected]>

…te loop (backport #50561) (#50787) Signed-off-by: sevev <[email protected]> Co-authored-by: zhangqiang <[email protected]>

…te loop (StarRocks#50561) ## Why I'm doing: Some `VERSION_INCOMPLETE` replicas may not be able to be scheduled for clone repair, such as the following scenario: 1. The partition visible version is `100` because there are some replica version is still `100` and version `101` publish failed. 2. The ingestion task is continuous and the lastest committed version is `120`. 3. There are two VERSION_INCOMPLETE` replicas, the first replica commit version `101` and `120` failed, so the first replica version is `100`, last failed version is `120`. The second replica commit version `102` and `108` failed, so the second replica version is `101` and the last failed version is `108`. 5. We consider these two replicas are needed to repair because their `last failed version` are both greater than 0 and we will choose the replica which `last failed version` is smaller to repair first. 6. However, we use visible version in clone task because the clone task can only clone the data with visible version. So the second replica version is still `101` and last failed version is `108`. 7. After clone, the second version is still `VERSION_INCOMPLETE` and we will try to repair again and again which cause the first replica can not repair any more and the the partition visible version is blocked. ## What I'm doing: Try to fix the replica which version is smaller first. Signed-off-by: sevev <[email protected]>

…te loop (backport #50561) (#50779) Co-authored-by: zhangqiang <[email protected]>

…te loop (StarRocks#50561) ## Why I'm doing: Some `VERSION_INCOMPLETE` replicas may not be able to be scheduled for clone repair, such as the following scenario: 1. The partition visible version is `100` because there are some replica version is still `100` and version `101` publish failed. 2. The ingestion task is continuous and the lastest committed version is `120`. 3. There are two VERSION_INCOMPLETE` replicas, the first replica commit version `101` and `120` failed, so the first replica version is `100`, last failed version is `120`. The second replica commit version `102` and `108` failed, so the second replica version is `101` and the last failed version is `108`. 5. We consider these two replicas are needed to repair because their `last failed version` are both greater than 0 and we will choose the replica which `last failed version` is smaller to repair first. 6. However, we use visible version in clone task because the clone task can only clone the data with visible version. So the second replica version is still `101` and last failed version is `108`. 7. After clone, the second version is still `VERSION_INCOMPLETE` and we will try to repair again and again which cause the first replica can not repair any more and the the partition visible version is blocked. ## What I'm doing: Try to fix the replica which version is smaller first. Signed-off-by: sevev <[email protected]> Signed-off-by: zhiminr.ren <[email protected]>

BugFix: Fix the bug in the FE clone scheduling that causes an infinit…

0ca2955

…e loop Signed-off-by: sevev <[email protected]>

sevev requested a review from a team as a code owner September 2, 2024 09:57

github-actions bot added 3.3 3.2 3.1 labels Sep 2, 2024

mergify bot assigned sevev Sep 2, 2024

sevev added 4 commits September 2, 2024 19:00

update

74cb37e

Signed-off-by: sevev <[email protected]>

add ut

98a9f34

Signed-off-by: sevev <[email protected]>

update

a20fa2f

Signed-off-by: sevev <[email protected]>

update

07f1b94

Signed-off-by: sevev <[email protected]>

gengjun-git self-assigned this Sep 4, 2024

gengjun-git approved these changes Sep 5, 2024

View reviewed changes

HangyuanLiu requested a review from gengjun-git September 6, 2024 02:20

HangyuanLiu approved these changes Sep 6, 2024

View reviewed changes

sevev merged commit 19b833f into StarRocks:main Sep 6, 2024
49 checks passed

github-actions bot removed the 3.3 label Sep 6, 2024

github-actions bot removed the 3.2 label Sep 6, 2024

github-actions bot removed the 3.1 label Sep 6, 2024

wanpengfei-git pushed a commit that referenced this pull request Sep 6, 2024

[BugFix] Fix the bug in the FE clone scheduling that causes an infini…

d30791c

…te loop (backport #50561) (#50780) Co-authored-by: zhangqiang <[email protected]>

github-actions bot added the 3.1-merged label Sep 6, 2024

mergify bot mentioned this pull request Sep 6, 2024

[BugFix] Fix the bug in the FE clone scheduling that causes an infinite loop (backport #50561) #50787

Merged

42 tasks

wanpengfei-git pushed a commit that referenced this pull request Sep 6, 2024

[BugFix] Fix the bug in the FE clone scheduling that causes an infini…

cc379e8

…te loop (backport #50561) (#50778) Co-authored-by: zhangqiang <[email protected]>

github-actions bot added the 3.3-merged label Sep 6, 2024

xiangguangyxg pushed a commit to xiangguangyxg/starrocks that referenced this pull request Sep 6, 2024

[BugFix] Fix the bug in the FE clone scheduling that causes an infini…

840d2ee

…te loop (backport StarRocks#50561) (StarRocks#50778) Co-authored-by: zhangqiang <[email protected]>

wanpengfei-git pushed a commit that referenced this pull request Sep 9, 2024

[BugFix] Fix the bug in the FE clone scheduling that causes an infini…

7207d3a

…te loop (backport #50561) (#50787) Signed-off-by: sevev <[email protected]> Co-authored-by: zhangqiang <[email protected]>

github-actions bot added the 2.5-merged label Sep 9, 2024

wanpengfei-git pushed a commit that referenced this pull request Sep 23, 2024

[BugFix] Fix the bug in the FE clone scheduling that causes an infini…

91fd96d

…te loop (backport #50561) (#50779) Co-authored-by: zhangqiang <[email protected]>

github-actions bot added the 3.2-merged label Sep 23, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BugFix] Fix the bug in the FE clone scheduling that causes an infinite loop #50561

[BugFix] Fix the bug in the FE clone scheduling that causes an infinite loop #50561

sevev commented Sep 2, 2024

sonarcloud bot commented Sep 3, 2024

github-actions bot commented Sep 3, 2024

github-actions bot commented Sep 3, 2024

github-actions bot commented Sep 3, 2024

github-actions bot commented Sep 6, 2024

github-actions bot commented Sep 6, 2024

github-actions bot commented Sep 6, 2024

mergify bot commented Sep 6, 2024 •

edited

Loading

mergify bot commented Sep 6, 2024 •

edited

Loading

mergify bot commented Sep 6, 2024 •

edited

Loading

sevev commented Sep 6, 2024

mergify bot commented Sep 6, 2024 •

edited

Loading

[BugFix] Fix the bug in the FE clone scheduling that causes an infinite loop #50561

[BugFix] Fix the bug in the FE clone scheduling that causes an infinite loop #50561

Conversation

sevev commented Sep 2, 2024

Why I'm doing:

What I'm doing:

What type of PR is this:

Checklist:

Bugfix cherry-pick branch check:

sonarcloud bot commented Sep 3, 2024

Quality Gate passed

github-actions bot commented Sep 3, 2024

[Java-Extensions Incremental Coverage Report]

github-actions bot commented Sep 3, 2024

[FE Incremental Coverage Report]

file detail

github-actions bot commented Sep 3, 2024

[BE Incremental Coverage Report]

github-actions bot commented Sep 6, 2024

github-actions bot commented Sep 6, 2024

github-actions bot commented Sep 6, 2024

mergify bot commented Sep 6, 2024 • edited Loading

✅ Backports have been created

mergify bot commented Sep 6, 2024 • edited Loading

✅ Backports have been created

mergify bot commented Sep 6, 2024 • edited Loading

✅ Backports have been created

sevev commented Sep 6, 2024

mergify bot commented Sep 6, 2024 • edited Loading

✅ Backports have been created

mergify bot commented Sep 6, 2024 •

edited

Loading

mergify bot commented Sep 6, 2024 •

edited

Loading

mergify bot commented Sep 6, 2024 •

edited

Loading

mergify bot commented Sep 6, 2024 •

edited

Loading