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

Moved automatic splits to the manager #3382

Merged
merged 3 commits into from
May 18, 2023

Conversation

keith-turner
Copy link
Contributor

@keith-turner keith-turner commented May 5, 2023

I took this out of draft. The following the message from the commit.

    The Manager now scans tablets looking for ones that need to split.  When
    it finds one it queues it on a thread pool for inspection of files to
    find a split point.  When split points are found a FATE operation is
    initiated to do the splits.  The FATE operation uses conditional
    mutations to syncronize access to the tablet metadata.  The FATE
    operation creates one or more new tablets in the metadata table. Unlike
    the the old split code which could only split a tablet into two, this
    new code can split a tablet into however many are needed in a single
    operation.  This makes responding to a change in the split threshold
    much faster.
    
    The old code used to shorten split points, this change carries that
    behavior forward in the new code to find multiple split points.
    
    This change does not include moving user intiated splits into the
    manager, that will be done in a follow on change.

@@ -1273,6 +1323,10 @@ boolean canSuspendTablets() {
throw new IllegalStateException("Exception updating manager lock", e);
}

// TODO shut this down later? Is this the correct place to start this?
this.splitter = new Splitter(context, DataLevel.USER, this);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason not to make this part of the TabletGroupWatcher?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not that I know of, I did not start there because I was unsure if that was the best path and I wanted to get some basic functionality working. I think that would be a good follow on issue to explore.

The Manager now scans tablets looking for ones that need to split.  When
it finds one it queues it on a thread pool for inspection of files to
find a split point.  When split points are found a FATE operation is
initiated to do the splits.  The FATE operation uses conditional
mutations to syncronize access to the tablet metadata.  The FATE
operation creates one or more new tablets in the metadata table. Unlike
the the old split code which could only split a tablet into two, this
new code can split a tablet into however many are needed in a single
operation.  This makes responding to a change in the split threshold
much faster.

The old code used to shorten split points, this change carries that
behavior forward in the new code to find multiple split points.

This change does not include moving user intiated splits into the
manager, that will be done in a follow on change.
@keith-turner keith-turner force-pushed the splitting-in-manager3 branch from 788321a to 7bdef27 Compare May 12, 2023 22:44
@keith-turner keith-turner marked this pull request as ready for review May 12, 2023 22:44
@keith-turner
Copy link
Contributor Author

There were many TODOs in this code. Opened follow on issues for them #3406,#3407,#3408,#3410,#3411,#3412, and #3413

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Offline operations: Move all split functionality from tablets server to manager
3 participants