[jira] [Commented] (HBASE-26640) Reimplement master local region initialization to better work with SFT
[ https://issues.apache.org/jira/browse/HBASE-26640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572122#comment-17572122 ] Huaxiang Sun commented on HBASE-26640: -- The change now is in 2.5.0-snapshot, do we need to change the release version to 2.5.0? [~zhangduo] Also if it downgrades from 2.5.0 to 2.4.*, do you see any imcompatible change besides HBASE-27251? Thanks. > Reimplement master local region initialization to better work with SFT > -- > > Key: HBASE-26640 > URL: https://issues.apache.org/jira/browse/HBASE-26640 > Project: HBase > Issue Type: Sub-task > Components: master, RegionProcedureStore >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.6.0, 3.0.0-alpha-3 > > > It is not like a normal region where we have a TableDescriptor so it can > store the SFT implementation of its own. In the current implementation, if we > change the global SFT configuration, the SFT implementation of the master > local reigon will be changed and cause data loss. > First I think we could hard coded it to use DefaultSFT. The region is small > and will not cause too much performance impact. Then we could find a way to > manage the SFT implementation of it. > == Update == > The initialization of master local region depends on renaming, which can not > work well on OSS. So we should also change it. The basic idea is to touch a > '.initialized' file to indicate it is initialized. Need to consider how to > migrate from the existing master local region where it does not have this > file. > And we could also store the TableDescriptor on file system, so we can > determine whether this is a SFT change. If so, we should do the migration > before actually opening the master local region. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (HBASE-26640) Reimplement master local region initialization to better work with SFT
[
https://issues.apache.org/jira/browse/HBASE-26640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512920#comment-17512920
]
Hudson commented on HBASE-26640:
Results for branch branch-2.5
[build #78 on
builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/78/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/78/General_20Nightly_20Build_20Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/78/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/78/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/78/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console
output|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2.5/78//console].
> Reimplement master local region initialization to better work with SFT
> --
>
> Key: HBASE-26640
> URL: https://issues.apache.org/jira/browse/HBASE-26640
> Project: HBase
> Issue Type: Sub-task
> Components: master, RegionProcedureStore
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 2.6.0, 3.0.0-alpha-3
>
>
> It is not like a normal region where we have a TableDescriptor so it can
> store the SFT implementation of its own. In the current implementation, if we
> change the global SFT configuration, the SFT implementation of the master
> local reigon will be changed and cause data loss.
> First I think we could hard coded it to use DefaultSFT. The region is small
> and will not cause too much performance impact. Then we could find a way to
> manage the SFT implementation of it.
> == Update ==
> The initialization of master local region depends on renaming, which can not
> work well on OSS. So we should also change it. The basic idea is to touch a
> '.initialized' file to indicate it is initialized. Need to consider how to
> migrate from the existing master local region where it does not have this
> file.
> And we could also store the TableDescriptor on file system, so we can
> determine whether this is a SFT change. If so, we should do the migration
> before actually opening the master local region.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (HBASE-26640) Reimplement master local region initialization to better work with SFT
[
https://issues.apache.org/jira/browse/HBASE-26640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17497912#comment-17497912
]
Hudson commented on HBASE-26640:
Results for branch branch-2
[build #468 on
builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/468/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/468/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/468/JDK8_20Nightly_20Build_20Report_20_28Hadoop2_29/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/468/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-2/468/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Reimplement master local region initialization to better work with SFT
> --
>
> Key: HBASE-26640
> URL: https://issues.apache.org/jira/browse/HBASE-26640
> Project: HBase
> Issue Type: Sub-task
> Components: master, RegionProcedureStore
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 2.6.0, 3.0.0-alpha-3
>
>
> It is not like a normal region where we have a TableDescriptor so it can
> store the SFT implementation of its own. In the current implementation, if we
> change the global SFT configuration, the SFT implementation of the master
> local reigon will be changed and cause data loss.
> First I think we could hard coded it to use DefaultSFT. The region is small
> and will not cause too much performance impact. Then we could find a way to
> manage the SFT implementation of it.
> == Update ==
> The initialization of master local region depends on renaming, which can not
> work well on OSS. So we should also change it. The basic idea is to touch a
> '.initialized' file to indicate it is initialized. Need to consider how to
> migrate from the existing master local region where it does not have this
> file.
> And we could also store the TableDescriptor on file system, so we can
> determine whether this is a SFT change. If so, we should do the migration
> before actually opening the master local region.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (HBASE-26640) Reimplement master local region initialization to better work with SFT
[
https://issues.apache.org/jira/browse/HBASE-26640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17497639#comment-17497639
]
Hudson commented on HBASE-26640:
Results for branch master
[build #520 on
builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/master/520/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/master/520/General_20Nightly_20Build_20Report/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/master/520/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/master/520/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Reimplement master local region initialization to better work with SFT
> --
>
> Key: HBASE-26640
> URL: https://issues.apache.org/jira/browse/HBASE-26640
> Project: HBase
> Issue Type: Sub-task
> Components: master, RegionProcedureStore
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 2.6.0, 3.0.0-alpha-3
>
>
> It is not like a normal region where we have a TableDescriptor so it can
> store the SFT implementation of its own. In the current implementation, if we
> change the global SFT configuration, the SFT implementation of the master
> local reigon will be changed and cause data loss.
> First I think we could hard coded it to use DefaultSFT. The region is small
> and will not cause too much performance impact. Then we could find a way to
> manage the SFT implementation of it.
> == Update ==
> The initialization of master local region depends on renaming, which can not
> work well on OSS. So we should also change it. The basic idea is to touch a
> '.initialized' file to indicate it is initialized. Need to consider how to
> migrate from the existing master local region where it does not have this
> file.
> And we could also store the TableDescriptor on file system, so we can
> determine whether this is a SFT change. If so, we should do the migration
> before actually opening the master local region.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
