[
https://issues.apache.org/jira/browse/HBASE-9514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13769761#comment-13769761
]
Enis Soztutar commented on HBASE-9514:
--------------------------------------
bq. We have waited for longer than the ZK session timeout. It should be
expired. It is ok to expire twice.
My understanding is that server expiry should ONLY come from a zookeeper
session timeout. The master being not able to connect to RS for more than zk
session timeout does not necessarily mean that the session has actually
expired. If a network partition happens and master cannot talk to RS, but RS
still holds the zk lease, then the master will think that the server is dead,
while RS will happily continue to serve the region. Given that the RS will be
getting YouAreDeadException if it talks the master afterwards, and we are
forcing lease recovery on the RS logs on log splitting, but I fear, while this
process is going on there will be an inconsistency window where master will
think RS is dead, while it may not be.
> Prevent region from assigning before log splitting is done
> ----------------------------------------------------------
>
> Key: HBASE-9514
> URL: https://issues.apache.org/jira/browse/HBASE-9514
> Project: HBase
> Issue Type: Bug
> Components: Region Assignment
> Reporter: Jimmy Xiang
> Assignee: Jimmy Xiang
> Priority: Blocker
> Attachments: trunk-9514_v1.patch
>
>
> If a region is assigned before log splitting is done by the server shutdown
> handler, the edits belonging to this region in the hlogs of the dead server
> will be lost.
> Generally this is not an issue if users don't assign/unassign a region from
> hbase shell or via hbase admin. These commands are marked for experts only in
> the hbase shell help too. However, chaos monkey doesn't care.
> If we can prevent from assigning such regions in a bad time, it would make
> things a little safer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
