-
Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-26587 Introduce a new Admin API to change SFT implementation #4030
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
Conversation
Still need to add more tests, at lease for AsyncAdmin. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
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.
Other than a naming suggestion change, looks pretty good. Thinking out loud: this change doesn't require a change in hbase shell, so that's good.
@@ -2590,7 +2620,20 @@ String getOperationType() { | |||
|
|||
@Override | |||
String getOperationType() { | |||
return "ENABLE"; | |||
return "MODIFY"; |
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.
:) good catch
hbase-client/src/main/java/org/apache/hadoop/hbase/client/RawAsyncHBaseAdmin.java
Outdated
Show resolved
Hide resolved
} | ||
|
||
private enum StoreFileTrackerState { | ||
NEED_RESTORE, NEED_MIGRATION, NEED_FINISH_MIGRATION, ALREADY_FINISHED |
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.
NEED_RESTORE
was a bit confusing to me and I had to read to understand what it meant. What about:
NEED_RESTORE
->NEED_SET_MIGRATION
NEED_MIGRATION
->NEED_START_MIGRATION
NEED_FINISH_MIGRATION
(perfect)
If you like this, should also change the constant up in 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.
Finally I name them as
NEED_FINISH_PREVIOUS_MIGRATION_FIRST
NEED_START_MIGRATION
NEED_FINISH_MIGRATION
ALREADY_FINISHED
And on the procedure state, I name them as
MODIFY_STORE_FILE_TRACKER_FINISH_PREVIOUS_MIGRATION
MODIFY_STORE_FILE_TRACKER_START_MIGRATION
MODIFY_STORE_FILE_TRACKER_FINISH_MIGRATION
Is this clear enough for you?
Thanks.
.../apache/hadoop/hbase/regionserver/storefiletracker/ModifyTableStoreFileTrackerProcedure.java
Show resolved
Hide resolved
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAdmin3.java
Show resolved
Hide resolved
Yes, we do not change the existing method so we do not need to change hbase shell right now. Filed HBASE-26673 for implementing the shell commands for this operation. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
Any other concerns? @joshelser |
Ping @joshelser . I think this is an important feature. After this we could introduce new shell command to migrate the all the tables for a cluster. Thanks. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
@joshelser Mind taking a look again? There is a 'change requested' so without your comment we can not go ahead... Thanks. |
hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift2/client/ThriftAdmin.java
Outdated
Show resolved
Hide resolved
hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift2/client/ThriftAdmin.java
Outdated
Show resolved
Hide resolved
StoreFileTrackerState state = checkState(conf, dstSFT); | ||
switch (state) { | ||
case NEED_FINISH_PREVIOUS_MIGRATION_FIRST: | ||
TableDescriptor td = createRestoreTableDescriptor(current, getRestoreSFT(conf)); |
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'm a bit confused here. Say we have three impls and the migration. Currently using impl1 and we submit migration to dst=impl2 (this triggers a MSFTP #1), followed by another migration to dst=impl3 (this triggers a MSFTP #2), then here we simply add a MTP to set impl2 tracker straight (no migration)? What if MSFTP #1 hasn't finished when this MTP starts run?
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.
What do you mean by "if MSFTP #1 hasn't finished when this MTP starts run"? The parent procedure can only resume execution when the child procedures are done. So there will be no overlap.
And typically, we only need to schedule two MTP, which is the flow starts from NEED_START_MIGRATION. First MTP changes the SFT implementation to MIGRATION, and the second MTP changes the SFT implementation to the dst implementation.
And why we need NEED_FINISH_PREVIOUS_MIGRATION_FIRST, is because we need to consider the situation where the SFT implementation is already MIGRATION, then we need to finish the MIGRATION by scheduling a MTP first. Then we can go back to the above logic to do the migration. Of course if the dst implementation the current MIGRATION is exactly what we want, then finish it is enough for us. That's why we have the logic in preCheckAndTryRestoreSFT.
I could try to add more comments here to explain the logic.
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.
Oh we already have comments in getState method. PTAL if it is clear enough for you @wchevreuil ? Thanks.
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.
What do you mean by "if MSFTP #1 hasn't finished when this MTP starts run"? The parent procedure can only resume execution when the child procedures are done. So there will be no overlap.
What I meant is if two, subsequent, "change SFT" commands are triggered. Those would trigger separate "MSFTPs", with then independent child "MTPs". Or does a "MSFTP" hold a lock on the table, preventing this from happening?
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.
We hold exclusive lock on the table, same as MTP. We will release the lock between steps but there is no difference between MTP. I can not recall how this is handled or we just do not care, could dig more later. But anyway, there is no difference with the current MTP implementation.
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.
In TestModifyTableProcedure, there are several tests which run ModifyTableProcedure concurrently. I changed the log at the beginning of the executeFromState method of ModifyTableProcedure to debug, and find out that, although we scheduled the two MTP at almost the same time, the exeuction flow was always that, one MTP would wait for another to finish before executing...
Need to dig more. But anyway, I do not think this is a blocker issue for this PR?
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.
No, I think if no two MTPs can run concurrently, this is safe enough.
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
Hi, @joshelser ,do you still have any more concerns on this PR? Thanks. |
Anyway, I think we have already waited enough time... Let me merge the PR. |
…pache#4030) Signed-off-by: Wellington Ramos Chevreuil <wchevreuil@apache.org> Reviewed-by: Josh Elser <elserj@apache.org>
…pache#4030) (apache#4080) Signed-off-by: Wellington Ramos Chevreuil <wchevreuil@apache.org> Reviewed-by: Josh Elser <elserj@apache.org>
…pache#4030) (apache#4080) Signed-off-by: Wellington Ramos Chevreuil <wchevreuil@apache.org> Reviewed-by: Josh Elser <elserj@apache.org>
…pache#4030) (apache#4080) Signed-off-by: Wellington Ramos Chevreuil <wchevreuil@apache.org> Reviewed-by: Josh Elser <elserj@apache.org>
…pache#4030) (apache#4080) Signed-off-by: Wellington Ramos Chevreuil <wchevreuil@apache.org> Reviewed-by: Josh Elser <elserj@apache.org>
…pache#4030) (apache#4080) Signed-off-by: Wellington Ramos Chevreuil <wchevreuil@apache.org> Reviewed-by: Josh Elser <elserj@apache.org> Change-Id: I2668783c0903641ebef24d53d8e30018829735b8
No description provided.