[
https://issues.apache.org/jira/browse/HBASE-22923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17371229#comment-17371229
]
Viraj Jasani edited comment on HBASE-22923 at 6/29/21, 9:50 AM:
----------------------------------------------------------------
{quote}[~vjasani] Way back when RSGroups was first proposed, there were
concerns about it, and to resolve those concerns the community imposed this
requirement: _All RSgroups changes must be optional, and confined to the
hbase-rsgroups module_, with only case by case exceptions for enabling plug
points in hbase-server and other core modules. This requirement demanded the
admin APIs for rsgroups should also be in the hbase-rsgroups module, and this
is the reason for RSGroupInfoManager.
{quote}
I see, makes sense.
{quote}This behavior is introduced specifically for rolling upgrade, because
META might need to be migrated, and earlier thinking was a regionserver could
do it, but latest thinking is it is better for the master to migrate META and
other tables
{quote}
Agree, this behaviour is in line with any incompatible changes: user table
region hosted on higher version RS can face issues connecting to meta hosted on
lower version RS due to various reasons: coproc endpoint or schema
incompatibilities.
{quote}At the very least we can make it optional.
{quote}
Yeah that's better idea. In fact, we can introduce config for min version
required to move system tables to. That would be much better. This way,
operator would be willing to live with meta and other system table regions
continue to live on lower versioned RS. In major case, we would want to define
the value as next major version (assuming meta schema and coproc changes
introduced in major version). For instance, setting min version to "2.0.0"
would mean during upgrade from 1.6.0 -> 1.6.1 -> 1.7.0 would not have to worry
about moving system regions to higher versioned RS but anytime we upgrade to
HBase 2, AM will assign system table regions to higher versioned RS.
Will come up with PR soon. Thank you [~apurtell]!
was (Author: vjasani):
{quote}[~vjasani] Way back when RSGroups was first proposed, there were
concerns about it, and to resolve those concerns the community imposed this
requirement: _All RSgroups changes must be optional, and confined to the
hbase-rsgroups module_, with only case by case exceptions for enabling plug
points in hbase-server and other core modules. This requirement demanded the
admin APIs for rsgroups should also be in the hbase-rsgroups module, and this
is the reason for RSGroupInfoManager.
{quote}
I see, makes sense.
{quote}This behavior is introduced specifically for rolling upgrade, because
META might need to be migrated, and earlier thinking was a regionserver could
do it, but latest thinking is it is better for the master to migrate META and
other tables
{quote}
Agree, this behaviour is in line with any incompatible changes: user table
region hosted on higher version RS can face issues connecting to meta hosted on
lower version RS.
{quote}At the very least we can make it optional.
{quote}
Yeah that's better idea. In fact, we can introduce config for min version
required to move system tables to. That would be much better. This way,
operator would be willing to live with meta and other system table regions
continue to live on lower versioned RS. In major case, we would want to define
the value as next major version (assuming meta schema and coproc changes
introduced in major version). For instance, setting min version to "2.0.0"
would mean during upgrade from 1.6.0 -> 1.6.1 -> 1.7.0 would not have to worry
about moving system regions to higher versioned RS but anytime we upgrade to
HBase 2, AM will assign system table regions to higher versioned RS.
Will come up with PR soon. Thank you [~apurtell]!
> hbase:meta is assigned to localhost when we downgrade the hbase version
> -----------------------------------------------------------------------
>
> Key: HBASE-22923
> URL: https://issues.apache.org/jira/browse/HBASE-22923
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.4.8
> Reporter: wenbang
> Assignee: Viraj Jasani
> Priority: Major
>
> When we downgrade the hbase version（rsgroup enable）, we found that the
> hbase:meta table could not be assigned.
> {code:java}
> master.AssignmentManager: Failed assignment of hbase:meta,,1.1588230740 to
> localhost,1,1, trying to assign elsewhere instead; try=1 of 10
> java.io.IOException: Call to localhost/127.0.0.1:1 failed on local exception:
> org.apache.hadoop.hbase.ipc.FailedServerException: This server is in the
> failed servers list: localhost/127.0.0.1:1
> {code}
> hbase group list:
> HBASE_META group（hbase:meta and other system tables）
> default group
> 1.Down grade all servers in HBASE_META first
> 2.higher version servers is in default
> 3.hbase:meta assigned to localhost
> For system table, we assign them to a server with highest version.
> AssignmentManager#getExcludedServersForSystemTable
> But did not consider the rsgroup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
