Skip to content
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

Add revertSegmentReplacement API #7662

Merged

Conversation

snleee
Copy link
Contributor

@snleee snleee commented Oct 29, 2021

When all the segmentsFrom are 'ONLINE' state, this new API allows
to revert the segment replacement and use the original segments
when routing the query. This will be useful when the bad data
gets pushed and wants to go back to the previous state quickly.

@snleee snleee force-pushed the add-revert-segment-replacement-protocol branch from d1d8d41 to 4e68a6e Compare October 29, 2021 01:37
@snleee snleee requested a review from jackjlli October 29, 2021 01:38
@snleee snleee force-pushed the add-revert-segment-replacement-protocol branch from 4e68a6e to 07750bb Compare October 29, 2021 01:41
@codecov-commenter
Copy link

codecov-commenter commented Oct 29, 2021

Codecov Report

Merging #7662 (3e70968) into master (127f4c3) will decrease coverage by 0.15%.
The diff coverage is 18.75%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #7662      +/-   ##
============================================
- Coverage     71.67%   71.52%   -0.16%     
- Complexity     3996     4037      +41     
============================================
  Files          1576     1578       +2     
  Lines         80037    80363     +326     
  Branches      11865    11942      +77     
============================================
+ Hits          57366    57479     +113     
- Misses        18805    19003     +198     
- Partials       3866     3881      +15     
Flag Coverage Δ
integration1 28.96% <12.50%> (-0.36%) ⬇️
integration2 27.69% <0.00%> (+0.09%) ⬆️
unittests1 68.66% <100.00%> (-0.02%) ⬇️
unittests2 14.55% <10.93%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...ntroller/helix/core/PinotHelixResourceManager.java 62.32% <7.89%> (-1.60%) ⬇️
...ces/PinotSegmentUploadDownloadRestletResource.java 61.08% <23.52%> (-2.38%) ⬇️
...troller/helix/core/retention/RetentionManager.java 82.75% <50.00%> (-0.72%) ⬇️
...apache/pinot/common/lineage/LineageEntryState.java 100.00% <100.00%> (ø)
...data/manager/realtime/SegmentCommitterFactory.java 64.70% <0.00%> (-29.42%) ⬇️
...ot/core/query/pruner/ColumnValueSegmentPruner.java 74.86% <0.00%> (-19.31%) ⬇️
.../common/request/context/predicate/EqPredicate.java 66.66% <0.00%> (-13.34%) ⬇️
...unction/DistinctCountHLLMVAggregationFunction.java 17.16% <0.00%> (-10.91%) ⬇️
...nction/DistinctCountBitmapAggregationFunction.java 41.96% <0.00%> (-10.89%) ⬇️
...er/api/resources/LLCSegmentCompletionHandlers.java 53.46% <0.00%> (-8.92%) ⬇️
... and 57 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 127f4c3...3e70968. Read the comment docs.

segmentLineageEntryId));

// Revert is not allowed if the state is not 'COMPLETED'
if (lineageEntry.getState() != LineageEntryState.COMPLETED) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if the lineage entry is currently in IN_PROGRESS state, let's say a batch of segment upload is interrupted? Are we still able to mark it to REVERTED?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1. We should allow explicitly revert IN_PROGRESS lineage (add a flag is fine) in case user knows the the segment upload is already interrupted

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point. I added forceRevert flag so that the user can explicitly revert the lineage entry even if it's IN_PROGRESS.

Copy link
Contributor

@Jackie-Jiang Jackie-Jiang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should also modify startReplaceSegments and ignore the segmentsFrom check for REVERTED lineage. User'll likely start another segment replace with the same source segments.

Do we need to modify the broker routing logic? Can we add a test to verify the broker behavior on REVERTED lineage?

segmentLineageEntryId));

// Revert is not allowed if the state is not 'COMPLETED'
if (lineageEntry.getState() != LineageEntryState.COMPLETED) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1. We should allow explicitly revert IN_PROGRESS lineage (add a flag is fine) in case user knows the the segment upload is already interrupted

@snleee snleee force-pushed the add-revert-segment-replacement-protocol branch 4 times, most recently from f0aa01e to 3508902 Compare November 1, 2021 21:02
When all the segmentsFrom are 'ONLINE' state, this new API allows
to revert the segment replacement and use the original segments
when routing the query. This will be useful when the bad data
gets pushed and wants to go back to the previous state quickly.
@snleee snleee force-pushed the add-revert-segment-replacement-protocol branch from 3508902 to 3e70968 Compare November 1, 2021 22:40
Copy link
Member

@jackjlli jackjlli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for working on it!

if (lineageEntry.getState() != LineageEntryState.COMPLETED) {
// We do not allow to revert the lineage entry with 'REVERTED' state. For 'IN_PROGRESS", we only allow to
// revert when 'forceRevert' is set to true.
if (lineageEntry.getState() != LineageEntryState.IN_PROGRESS || !forceRevert) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: this line can be merged with L2944?

Suggested change
if (lineageEntry.getState() != LineageEntryState.IN_PROGRESS || !forceRevert) {
if (lineageEntry.getState() == LineageEntryState.REVERTED || (lineageEntry.getState() == LineageEntryState.IN_PROGRESS && !forceRevert)) {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, I missed your review and I already checked in. I will address this when I file the follow-up PR for proactive deletion.

// routing table because it is possible that there has been no EV change but the routing result may be
// different after updating the lineage entry.
sendRoutingTableRebuildMessage(tableNameWithType);
return true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once the lineage is updated successfully, are we planning to proactively invoke the segment deletion? It will help the case that segmentsTo take a lot of disk spaces and will block segment uploading until retention manager cleans it up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. I will file the follow-up PRs for proactive segment delete.

@snleee snleee merged commit da98e8b into apache:master Nov 2, 2021
@snleee snleee deleted the add-revert-segment-replacement-protocol branch November 2, 2021 00:33
@snleee
Copy link
Contributor Author

snleee commented Nov 22, 2021

#7813

kriti-sc pushed a commit to kriti-sc/incubator-pinot that referenced this pull request Dec 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants