[jira] [Comment Edited] (HBASE-22923) hbase:meta is assigned to localhost when we downgrade the hbase version

["Viraj Jasani (Jira)" <ji...@apache.org>]

    [ 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)