[
https://issues.apache.org/jira/browse/HBASE-9514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13769660#comment-13769660
]
Jimmy Xiang commented on HBASE-9514:
------------------------------------
bq. should we rename AM.acquireLock -> AM.acquireRegionLock()
Sure, will do.
bq. Why not do this for meta?
Let me think how to cover meta as well.
bq. Is it safe to expire a server like this. It means the master cannot connect
to it, but it may still have the zk lease.
We have waited for longer than the ZK session timeout. It should be expired.
It is ok to expire twice.
The timeout should be active. I will fix it.
The idea of the patch is to remember the last known region server a region is
assigned to. Whenever we try to assign a region, we check if the last known
region server of the region is done with log splitting. If not, we don't assign
it, and let SSH to complete log splitting and re-assign. We clear the last
known region server info when SSH finishes log splitting, or the region is
properly closed. The idea is simple but there are several racing points to take
care.
> 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
