[
https://issues.apache.org/jira/browse/HBASE-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882245#action_12882245
]
stack commented on HBASE-2700:
------------------------------
The data in zk is proxy for actual state. It'll likely have holes,
misreporting whats actually out on the RS. Going to the source to ask it what
it actually has would seem less error-prone (less complex), no?
Regards a second list of regionservers up in zk, could you not here also look
at .META.? It's server cell has hostnames. Could compare this list to whats
up in zk as live RSs and then w/ the difference, go poke around in filesystem
to find logs to split?
My mine concern is that there seems to have been no consideration of how the
bible addresses this issue, if only a "we looked at it and discarded it because
of 1, 2, and 3". The zk approach sounds like it could be 'faster' but being a
representation of state, there is the possibility that its representation may
diverge from actual state.
As to keeping all in memory in master, reading the BT paper, I'm not sure if
that is what is going on. It would seem to indicate so in the sentence where
it describes how master learns of dropped splits but as you say, for big
clusters this may prove untenable.
> 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.
