[
https://issues.apache.org/jira/browse/HBASE-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13789642#comment-13789642
]
Elliott Clark commented on HBASE-5487:
--------------------------------------
bq.Wrt coprocs - that is bad imho, that is not the kind of modular that we want.
I'm not tied to it being a co-proc. But it does illustrate the idea that it
can be done by watching mutations as they come into the normal hregion call
stack.
bq.That is not due to ZK as such, that is due to multi-state-machine
reconciliation model and truth in multiple places that it requires.
In part it's due to getting zk messages out of order, and getting them delayed.
Those pains are due in no small part because zk's client is single threaded.
bq.System table can have exact same problem of state in the table + state in
memory, question is how you split and manage state between them, storage
substrate doesn't matter as much.
But you only have the one state if you have master inside of the region server
hosting meta. There's no need to have a map of assignment if meta is actually
just a function call away. Also The same is not true at all if you want to
put state into zk. Then you need a local cache if you want to make this
performant at all (That's how we got to the current state). Putting state into
zk necessitates a split brain problem. There's what the master see and what
the outside worlds sees.
bq.So, why would we write a bunch of new code to get "within an order of
magnitude"?
That code is already there, and in use. We fail over meta right now in 240ms.
I was commenting on what you were saying that zk fails over faster. And that's
true but for meta we've narrowed that gap significantly. So I don't think that
ZK has that much of an advantage.
bq. I don't see an advantage, or ZK disadvantage that you mention compared to
multiple advantages of ZK
We've tried putting state into zk. That failed. I really don't want to put a
whole bunch of new code into hbase that does almost exactly the same thing as
we currently have. It's going to fail.
bq.so the storage mechanism choice is almost orthogonal.
For me it's not just about the storage. It's about co-locating storage with
the master means that these split brain problems are much rarer.
> 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)
