[
https://issues.apache.org/jira/browse/HBASE-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882368#action_12882368
]
Jonathan Gray commented on HBASE-2700:
--------------------------------------
bq. 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.
Can you be more explicit here? I see you have no confidence in ZK but going
over the design multiple times I don't see where we would miss out on something
by look at ZK. Do you have any specific examples or situations where things
could be out of sync or something could be missed?
bq. If meta doesn't have the list of regions and their locations, clients are
not going to work.
What I mean to say is, a master may not know that a region has been opened on
an RS (has not received OPENED msg) but META would have that region assigned to
the RS. I need to think more about it but when I was thinking earlier I
thought I had situation where a region would get lost if RS was one doing meta
updates.
bq. I thought you said you can miss transitions in zk (Maybe you mean region
transitions?).
We can miss specific transitions but we'll always be able to recreate them
because ZK will always contain states. We could miss (in Master) the movement
from OPENING to OPENED or CLOSING to CLOSED, but we will never be able to miss
the OPENED state or CLOSED state because it is the master which does the next
transition out of those.
bq. For second list of RS up in ZK...
Thinking more, I think it's fine to use meta scan to determine RS list rather
than second list up in ZK.
bq. 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?
Agree we don't need second list. But I think it's unnecessary to query every
RS about what it hosts. We will have knowledge of every potentially unassigned
region in ZK which is the exact piece of information we're looking for.
bq. 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.
I'm interested in a scenario where region state up in zk is not sufficient or
not representative. Fair to question the design but we've been mulling over
bulletproofing region transitions for weeks and weeks and zk somehow not being
representative seems like a deal breaker to the entire thing?
> 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.
