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