[
https://issues.apache.org/jira/browse/HBASE-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13556116#comment-13556116
]
Jonathan Hsieh commented on HBASE-5487:
---------------------------------------
bq. My main point is that currently two external region states in ZK and a
table, plus two complex internal states in server and master, are a root of
some non-trivial part of all evil. Especially the nature of ZK state, that
comes and goes. Imho we should remove one of them from being actively managed.
bq. ZK has notifications and seems better suited for locking/atomic updates;
w.r.t. availability it has no disadvantage since everything (e.g. locating the
root) fails without ZK anyway, even if we do remove state machines from there.
bq. System tables are more native to HBase and have built-in WAL, plus have
advantages for recovery.
ZK notifications are useful when there are two way communications -- log
splitting, region server initiated splits. I do agree that opens and closes
seems more complicated than necessary.
bq. Maybe instead of WAL we can use ZK as universal source of region state (w/o
assorted transient nodes e.g. one node per region that is always there, or
maybe two if we want to use lock with lease to unassign) and mirror it to
system table that is only used for recovery like you describe, or when ZK state
disappears?
bq. Otherwise I think we should just use system table as universal source of
region state and get rid of ZK region state.
bq. With one source of truth master and server logic can probably be dumber.
Simpler, not dumber. :)
The 0.20/0.89 version of the master actually had most things in meta -- and
there are definitely some trade-offs with that approach. In the transition to
the 0.90 style master we traded some pain points for new ones. If we change
this again we need to make sure we keep those previous ones in mind to not
duplicate the worst of them again.
Is there any chance we could get a high level design deck/doc that illustrates
these processes currently and what looks like after we move to this proposed
FATE-like mechanism? Also, what operations would eventually get ported to this
mechanism? I think discussion and an example at the design/rpc comms level
would help a whole lot by grounding this conversion in reality and not require
diving into the code. Once we basically agree on design, code reviews would be
easier because they'd be focused on the implementation matching the design.
> Generic framework for Master-coordinated tasks
> ----------------------------------------------
>
> Key: HBASE-5487
> URL: https://issues.apache.org/jira/browse/HBASE-5487
> Project: HBase
> Issue Type: New Feature
> Components: master, regionserver, Zookeeper
> Affects Versions: 0.94.0
> Reporter: Mubarak Seyed
> Assignee: Nick Dimiduk
>
> Need a framework to execute master-coordinated tasks in a fault-tolerant
> manner.
> Master-coordinated tasks such as online-scheme change and delete-range
> (deleting region(s) based on start/end key) can make use of this framework.
> The advantages of framework are
> 1. Eliminate repeated code in Master, ZooKeeper tracker and Region-server for
> master-coordinated tasks
> 2. Ability to abstract the common functions across Master -> ZK and RS -> ZK
> 3. Easy to plugin new master-coordinated tasks without adding code to core
> components
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
