Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
HBASE-28215: region reopen procedure batching/throttling #5534
HBASE-28215: region reopen procedure batching/throttling #5534
Changes from 2 commits
2f30fec
a3a8804
32e08b2
36f7ee1
afa02f9
b8e21c9
8a9f8f4
08991b2
0d010a0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure we need to do this? What if we did something like this:
It feels cleaner to read and understand what's happening. As mentioned in another comment, I'd recommend updating REOPEN_REGIONS to:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed all around about the feedback here, just pushed a simplification that follows this advice almost exactly. The tests are all still passing of course
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the changes in this method are sort of confusing. I think the division of labor should be:
REOPEN_TABLE_REGIONS_REOPEN_REGIONS
-- breaks the set ofregions
into a smaller batch, and reopens that batch. The code you have for that looks okREOPEN_TABLE_REGIONS_CONFIRM_REOPENED
-- checks if any regions are still needing reopen. If so, go back to REOPEN_REGIONS. This is how it used to work.If we totally reverted the changes in REOPEN_TABLE_REGIONS_CONFIRM_REOPENED, I think we'd have successfully broken the full region list into batches and the flow would work, just without backoff. So in this method we really just need to add the backoff.
The backoff as you have it below looks ok at first glance. This is just a long winded way of saying we should drop the highlighted code :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this complexity is necessary in order to differentiate between
are there more regions to reopen
vsare regions still reopening in the current batch
, the former being a state change and fixed backoff, and the latter being a retry and exponentially increasing backoffThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's look back at the original impl of CONFIRM_REOPEN. It only does the backoff if there are still regions to reopen and none of them are schedulable. Meaning we back off in order to wait for regions to be schedulable.
Now let's look at your new code. I see what you are saying. You are basically doing:
The key thing there is that "process next batch". You'd think that would be "re-schedule existing batch". But as is, when you go to process next batch, the first thing REOPEN_REGIONS does is create a new currentRegionBatch. So lets say for the first batch of 50, only 10 reopen. With the current design, you'd expect it to try again to reopen those remaining 40. But it will actually reopen another 50 (40 of which are likely to have been in the last batch).
TBH I don't think there's a huge problem with that approach. But given that's how it works, we can simplify this code as I described before -- we don't really care about currentRegionBatch here, just that if any regions are left to reopen and schedulable.
If we wanted to do what I think you are intending to do, we probably need to complicate things a bit further. Maybe we update REOPEN_REGIONS to only create currentRegionBatch if it's currently null. Then in CONFIRM_REOPEN, null it out after confirming that they've been reopened. That way, in the above example when we kickoff REOPEN_REGIONS again we'll only open the remaining 40.
Does that make sense? Between these 2 options I might opt for the simpler one where we keep REOPEN_REGIONS as is and remove most of the diff from CONFIRM_REOPEN.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, after a discussion on https://issues.apache.org/jira/browse/HBASE-25549, i wonder if we should take the safer approach where require each batch to finish before scheduling more. This feature could serve a dual purpose of progressive rollout and rate limiting.
We could also trivially update this code to do an actual progressive deploy -- first batch size 1, then 2, then 4, etc up to the current batch size config you added. At that point it stays at that max concurrency until completion.
Thoughts on adding that? I think we just need one more field for
currentBatchSize
which we increment after each batch up toreopenBatchSize
. It might make sense to persist this new field in the proto.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's missing a few distinct outcomes of
CONFIRM_REOPENED
, and that's where this complexity comes into play. Here are the possibilities:REOPEN_REGIONS
and suspend. This will process the next batchREOPEN_REGIONS
to avoid an infinite loop due to a bypassed proc or something. This could technically reprocess the next batch, or redefine what the "current batch" looks like, but I think that's ok given the exceptional nature of this caseCONFIRM_REOPENED
and retry w/ increasing backoffIf I just revert this diff as described then this procedure will just get stuck in infinite loops (that I think could theoretically be exited if TRSP finishes quickly enough?) and all unit tests fail
I like this idea, and I think it would be trivial to add in the current state of this PR. We'd just need to store a maxReopenBatchSize and increase the reopenBatchSize to Math.min(2*reopenBatchSize, maxReopenBatchSize) each time we enter state 2 above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok lets table the missing outcomes/simplification discussion in that case, since we'll want to keep the current logic for the progressive reopen. We'll also want to do as i said, where in CONFIRM we update currentRegionBatch to filter out the reopened regions, and then in REOPEN we should only create a new currentRegionBatch if the existing isEmpty. That way if there's some problematic region in the batch, we won't move on to the next batch until its been reopened. Right now I think we'd just move on and create a new batch including the problematic region + more?
Once we have that in there, I need to take another look at the logic here. I think it could be a bit clearer, but don't want to make any suggestions until we have the complete impl in place.
In terms of progressive, it'd be nice to start with 1 region but otherwise agree with your Math.min idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, I just pushed a change which does the following:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a little confusing to read. Specifically, the way to backoff is by throwing
ProcedureSuspendedException
but below you are returningFlow.HAS_MORE_STATE
. It would be nice to indicate that the return only happens if we don't back-off. One way to do that would be to add a comment below. But it might be better to renamebackoff
tosetBackoffState()
and throw a ProcedureSuspendedException here. You're already throwing it below (which is redundant givenbackoff
throws it now)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One other thing to note -- since we do
skipPersistence()
, we won't persist the setNextState change above. I think this should be fine. The implication is that in the case of a crash/restart while the procedure is suspended, we might backoff twice which is not the end of the world.