[
https://issues.apache.org/jira/browse/HBASE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824435#comment-16824435
]
Sergey Shelukhin commented on HBASE-22254:
------------------------------------------
bq. bq. More resilient off-loading; right now off-loading fails for a subset of
regions in case of a single region failure; is never done on master restart,
etc.
bq. Say more.
In the existing code the decom API has if-offload block that tries to move all
the regions. The move procedure creation only seems to work for OPEN regions,
and presumably it can also fail for some other reason; any RIT (e.g.
opening/closing) or an error will thus terminate the loop and throw from the
API call, only moving part of the regions; server will be marked as
decommissioned but offloading will never be retried. I'm not sure if the API
call should fail or not (I kept the existing behavior), but I made the
offloading itself more resilient by trying all regions despite errors, and
saving the flag in the existing state.
bq. Add how to invoke this new option to RN?
Hmm, interesting, RN actually refers to decommissioning servers via adding
ZNodes manually, whereas the code in master says draining server tracker is
deprecated; I was wondering why the latter was watching znodes while only
master creates them, and removed that logic given the deprecation comments.
I think adding HBase shell command to call the API might make sense, let me
look into that.
bq. We could construct the manager w/o znode?
This is unit test path only (where we have no ZK or want to init with
handcrafted data "from ZK" after doing some state shennanigans), let me clean
it up a bit...
bq. Yeah, adding extra server listener seems to be an argument that this be a
facility in ServerManager rather than new Manager.
The server listener is inherited from DrainingServerTracker.
I was thinking about keeping the class name as DrainingServerTracker :)
I can merge into SM, but it seems like that would make the combined class too
big... wdyt?
Will update the patch shortly, the fix to the unit test is a one-character
change ("!" got reversed in one place)
> refactor and improve decommissioning logic
> ------------------------------------------
>
> Key: HBASE-22254
> URL: https://issues.apache.org/jira/browse/HBASE-22254
> Project: HBase
> Issue Type: Improvement
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Priority: Major
> Attachments: HBASE-22254.01.patch, HBASE-22254.patch
>
>
> Making some changes needed to support better decommissioning on large
> clusters and with container mode; to test those and add clarify I moved parts
> of decommissioning logic from HMaster, Draining tracker, and ServerManager
> into a separate class.
> Features added/improvements:
> 1) More resilient off-loading; right now off-loading fails for a subset of
> regions in case of a single region failure; is never done on master restart,
> etc.
> 2) Option to kill RS after off-loading (good for container mode HBase, e.g.
> on YARN).
> 3) Option to specify machine names only to decommission, for the API to be
> usable for an external system that doesn't care about HBase server names, or
> e.g. multiple RS in containers on the same node.
> 4) Option to replace existing decommissioning list instead of adding to it
> (the same; to avoid additionally remembering what was previously sent to
> HBase).
> 5) Tests, comments ;)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
