-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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-26640 The master local region should not be effected by the glo… #4009
Conversation
…bal SFT configuration change
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
@@ -83,6 +84,7 @@ | |||
public static final byte[] PROC_FAMILY = Bytes.toBytes("proc"); | |||
|
|||
private static final TableDescriptor TABLE_DESC = TableDescriptorBuilder.newBuilder(TABLE_NAME) | |||
.setValue(StoreFileTrackerFactory.TRACKER_IMPL, StoreFileTrackerFactory.Trackers.DEFAULT.name()) |
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 hope we could differentiate brand new clusters from migrating ones, so that entirely new clusters with FILE tracker enabled globally could benefit from not having DEFAULT (thus temp dirs and renames) at all. The main reason here is to safely get rid of hboss, until we have something relying in temp dirs/renames, we can't safely remove hboss from the picture.
And are you sure the table descriptor is not getting saved upon creation, then loaded on sub-sequent starts? MasterRegion.create seems to just read the table info from file system here. If so, we could just add the similar check, when loading, to set DEFAULT if no tracker config is found, whilst setting the global tracker config in the bootstrap.
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, we will not read table info from file system, it is just a region, not a table, when calling the method we pass a TableDescriptor in. Or another option is to hard coded to use FILE implementation for master local region, as it can also work for HDFS, not big harm. Then we need to do the migration at start up for an existing cluster.
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, we will not read table info from file system, it is just a region, not a table, when calling the method we pass a TableDescriptor in.
Yeah, just looked at MasterRegion.bootstrap
method. Maybe we could persist the TD, since we already have a table dir anyways?
Or another option is to hard coded to use FILE implementation for master local region, as it can also work for HDFS, not big harm. Then we need to do the migration at start up for an existing cluster.
I guess that would work too.
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.
Or maybe I could try to write a TableDescriptor on FileSystem, and implement something like an alter if the expected TableDescriptor is not the same with the stored one. But it will take a bit longer time.
🎊 +1 overall
This message was automatically generated. |
…bal SFT configuration change