[ 
https://issues.apache.org/jira/browse/HBASE-28158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18018783#comment-18018783
 ] 

Umesh Kumar Kumawat commented on HBASE-28158:
---------------------------------------------

When a Region server get crashed, we first split all the wals and then only 
create TransitRegionStateProcedure.

In the current implementation, for some duration when we are splitting the 
wal's we don't include all the regions of RS into rit list. Do you want to 
include those regions in rit list as soon as the the server crash happenes 
(creation of SCP) ? If yes, then how can we calculate the the start of the 
transition for those regions ? For now we calculate the startTime by the 
lastUpdateTime in the meta. If somehow we add those regions into the rit list, 
we have to find some way to calcuate the ritTime or we have to let it go. 

> Decouple RIT list management from TRSP invocation
> -------------------------------------------------
>
>                 Key: HBASE-28158
>                 URL: https://issues.apache.org/jira/browse/HBASE-28158
>             Project: HBase
>          Issue Type: Bug
>          Components: master, Region Assignment
>    Affects Versions: 2.6.0, 2.5.6, 3.0.0-beta-1
>            Reporter: Andrew Kyle Purtell
>            Priority: Major
>              Labels: pull-request-available
>
> Operators bypassed some in progress TRSPs leading to a state where some 
> regions were persistently in transition but hidden. Because the master builds 
> its list of regions in transition by tracking TRSP, the bypass of TRSP 
> removed the regions from the RIT list. 
> Although I can see from reading the code this is the expected behavior, it is 
> surprising for operators and should be changed. Operators expect that regions 
> that should be open but are not appear the master's RIT list, provided by 
> /rits.jsp, the output of the shell's 'rit' command, and in ClusterStatus.
> We should only remove a region from the RIT map when assignment reaches a 
> suitable terminal state.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to