[ 
https://issues.apache.org/jira/browse/HBASE-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792752#comment-13792752
 ] 

Jimmy Xiang commented on HBASE-9696:
------------------------------------

Fixing the unit test now. The overnight run is the same as the previous one: 
failure but no data loss.

The purpose of the pending state is to hold the split/merge till master is ok 
with it. Without that, if the master is not fast enough to process the events, 
the region could be split/merged while the master is moving the region around. 
For example, this is possible:
1. RS says to merge A and B to C, creates the merging node C;
2. RS completes the merge so that A and B are offline and C is online, merging 
node C is in merged state now;
3. Master moves A, since it hasn't got the event 1 or 2, master knows A is 
online in RS, sends a close and gets back NSR exception since it's offline 
there, so starts to assign it somewhere else.

The pending state idea is align with what we discussed in other jiras about the 
new AM design to make sure master knows/manages region transitions.


> Master recovery ignores online merge znode
> ------------------------------------------
>
>                 Key: HBASE-9696
>                 URL: https://issues.apache.org/jira/browse/HBASE-9696
>             Project: HBase
>          Issue Type: Bug
>          Components: master, Region Assignment
>            Reporter: Jimmy Xiang
>            Assignee: Jimmy Xiang
>             Fix For: 0.98.0, 0.96.1
>
>         Attachments: trunk-9696.patch, trunk-9696_v2.1.patch, 
> trunk-9696_v2.patch, trunk-9696_v3.patch, trunk-9696_v3.patch
>
>
> The online merge znode uses the new region to be created.  When master 
> restarts, the new region is still unknown if the merging is not completed. 
> Therefore the znode is ignored, which should not.  That means the two merging 
> regions could be moved around.  This could cause some data loss if we are not 
> luck.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to