You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Duo Zhang (JIRA)" <ji...@apache.org> on 2018/07/02 00:52:00 UTC

[jira] [Commented] (HBASE-20828) Finish-up AMv2 Design/List of Tenets/Specification of operation

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

Duo Zhang commented on HBASE-20828:
-----------------------------------

Talked with [~stack] offline with the high level design of AMv2, this is what we think is useful to make the implementation cleaner

1. Region will be created with CLOSED state.
2. For a region with a state other than OPEN state, there will be a RIT associated with it, and it will finally be transited to OPEN state(unless we are disabling the table)
3. Regions for a disabled table are in CLOSED state.
4. The typical transiting path: OPEN -> CLOSING -> CLOSED -> OPENING -> OPEN.
5. If a server is crashed, all regions on it will be transited to CLOSED directly without CLOSING state.
6. A RIT procedure will never fail, unless the target server is crashed, i.e, only SCP can break the execution of RIT procedure.

#6 is the most difficult part here. What in my mind is that, let's get rid of the AssignProcedure, UnassignProcedure, MoveRegionProcedure, and only introduce a single RegionTransition procedure. It can cover all the transiting life cycle of a region, and can also start/stop at a particular state, i.e, for creating a table or SCP, we could start from CLOSED state directly, and if we are disabling a table, we could let it stop at CLOSED state.

The advantage here will be that, we can make sure that there is only one RIT procedure for a region. In the old time, MRP is not a RIT so we may miss it... And also, the logic for breaking the execution of the RIT in SCP will be easier, if there is already a RIT for it, just tell it what to do, if not, schedule one. We do not need to fear that if there is a MRP and after we fail the UnassignProcedure it will schedule a AssignProcedure soon and cause something wrong...


> Finish-up AMv2 Design/List of Tenets/Specification of operation
> ---------------------------------------------------------------
>
>                 Key: HBASE-20828
>                 URL: https://issues.apache.org/jira/browse/HBASE-20828
>             Project: HBase
>          Issue Type: Umbrella
>          Components: amv2
>            Reporter: stack
>            Priority: Major
>
> AMv2 is missing specification. There are too many grey-areas still. Also missing are a concise listing of the tenets of AMv2 operation. Here are some examples:
>  * HBASE-19529 "Handle null states in AM": Asks how we should treat null state in hbase:meta. What does it 'mean'. We seem to treat it differently dependent on context. Needs clarification. [~Apache9] recently asked similar about the meaning of OFFLINE.
>  * Logging needs to have a particular form to help trace Procedure progress; needs a write-up.
> Lets fill in items to address in this umbrella issue. Can address in subissues and produce specification doc too. We have the below but these are mostly (incomplete) description for devs on pv2 and amv2; the specification is missing:
> http://hbase.apache.org/book.html#pv2
> http://hbase.apache.org/book.html#amv2
> (Other areas include addressing what is up w/ rollback -- when, how much, and when it is not appropriate -- as well as recommendation on Procedures coarseness, locking -- is it ok to lock table in alter table procedure for the life of the procedure? -- and so on).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)