[
https://issues.apache.org/jira/browse/HBASE-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790442#comment-13790442
]
Jimmy Xiang commented on HBASE-5487:
------------------------------------
I prefer not to use ZK since it's kind of the root cause of uncertainty: has
the master/region server got/processed the event? has the znode hijacked since
master/region server changes its mind?
We should store the state in meta table which is cached in the memory.
Whether to use coprocessor it is not a big concern to me. If we don't use
coprocessor, I prefer to use the master as the proxy to do all meta table
updates. Otherwise, we need to listen to something for updates.
We should not have another janitor/chore. If an action is failed, it must be
because of something unrecoverable by itself, not because of a bug in our code.
It should stay failed until the issue is resolved.
We need to have something like FATE in accumulo to queue/retry actions taking
several steps like split/merge/move.
It is a nice-to-have to keep a history of region state transition.
> 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
> Priority: Critical
> Attachments: Region management in Master.pdf
>
>
> 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 was sent by Atlassian JIRA
(v6.1#6144)
