[
https://issues.apache.org/jira/browse/HBASE-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882355#action_12882355
]
stack commented on HBASE-2700:
------------------------------
.bq In what situation does the data in ZK not have the actual state
ZK is mediating the open/close of regions. For the final word on what is
actually happening on a RS, I'd say asking the RS will be more reliable than
asking ZK.
.bq It seems to me that it is META which may not be up to date and META which
can change without the proper notifications being sent.
If meta doesn't have the list of regions and their locations, clients are not
going to work. Its a bug (I think we're clear on what zk is responsible for
and where meta takes over).
Regards your comment that Master then has to update meta rather than RS as you
prefer, where do you get that from? From the BT quote above: "Whenever this
scan encounters a tablet that is not already assigned, the master adds the
tablet to the set of unassigned tablets, which makes the tablet eligible for
tablet assignment." Sounds like master just adds the region to the unassigned
list.... which in our case is a queue up in zk.
.bq ZK allows us to ensure we never miss states and transitions.
I thought you said you can miss transitions in zk (Maybe you mean region
transitions?).
.bq For second list of RS up in ZK, we could get this data in META but what
about case where a RS died while something was getting assigned to it but it
did not finish opening and died?
Then it'll have nothing on it and no mention in .META.... it never existed and
it never took on data. Wheres the prob? The babysit process will restart it
and hopefully second time around it'll have more luck.
.bq ....persistent message passing via ZK is a better direction than the meta
scanning / per-rs check-in / heartbeating.
You overreach with the above. I'm talking about process master follows
assuming master role. I'm not talking about heartbeating+messagepayload. My
suggestion that we consider what the BT paper does is about getting what the RS
is carrying from the horse's mouth rather than from the mediator.... also,
seems like we can simplify some by doing away w/ a second RS list up in ZK?
.bq What if a single RS happens to be in a 10 second GC pause?
Then RS will be slow to respond to master (or to zk). Master can work on other
RS reportings meantime.
.bq What about race conditions between what is in META and what the RSs know
about?
What sort of race condiition are you thinking? Master asks the RS for what it
has. RS could even volunteer opening/closing states if that'd help (or master
can just see zk for transitions -- might be good to have both to help
understand state). It reads .META. for list of regions and servers. What do
think could go amiss?
.bq What if we see in META something is unassigned but the previous master
asked an RS to open it?
See above. RS could report openings or master can check zk or both.
On your second note, you have confidence that the representation of cluster
state that is up in zk is always true. I don't have the same confidence.
> Handle master failover for regions in transition
> ------------------------------------------------
>
> Key: HBASE-2700
> URL: https://issues.apache.org/jira/browse/HBASE-2700
> Project: HBase
> Issue Type: Sub-task
> Components: master, zookeeper
> Reporter: Jonathan Gray
> Priority: Critical
> Fix For: 0.21.0
>
>
> To this point in HBASE-2692 tasks we have moved everything for regions in
> transition into ZK, but we have not fully handled the master failover case.
> This is to deal with that and to write tests for it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
