[jira] [Commented] (HBASE-6059) Replaying recovered edits would make deleted data exist again

["ramkrishna.s.vasudevan (JIRA)" <ji...@apache.org>]

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

ramkrishna.s.vasudevan commented on HBASE-6059:
-----------------------------------------------

@Chunhui
This is a damn good one.  But still i find one problem is there in this.  A similar type of problem that you have reported. Pls correct me if am wrong.
In the same test case in the place where you are deleting the row 'r1' if i delete the row 'r2' also
{code}
del = new Delete(Bytes.toBytes("r"));
    htable.delete(del);
    resultScanner = htable.getScanner(new Scan());
    count = 0;
    while (resultScanner.next() != null) {
      count++;
    }
{code}
Now my seq id from the store files will be 0 only as nothing to get after major compaction. So still the same problem is occuring.  I tried to simulate this with the same test case that you added. 
May be we need someother way to know that the edit has been deleted out by a major compaction? Because as i see this problem that without major compaction there is no issue at all.
                
> Replaying recovered edits would make deleted data exist again
> -------------------------------------------------------------
>
>                 Key: HBASE-6059
>                 URL: https://issues.apache.org/jira/browse/HBASE-6059
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>            Reporter: chunhui shen
>            Assignee: chunhui shen
>         Attachments: HBASE-6059-testcase.patch, HBASE-6059.patch
>
>
> When we replay recovered edits, we used the minSeqId of Store, It may cause deleted data appeared again.
> Let's see how it happens. Suppose the region with two families(cf1,cf2)
> 1.put one data to the region (put r1,cf1:q1,v1)
> 2.move the region from server A to server B.
> 3.delete the data put by step 1(delete r1)
> 4.flush this region.
> 5.make major compaction for this region
> 6.move the region from server B to server A.
> 7.Abort server A
> 8.After the region is online, we could get the deleted data(r1,cf1:q1,v1)
> (When we replay recovered edits, we used the minSeqId of Store, because cf2 has no store files, so its seqId is 0, so the edit log of put data will be replayed to the region)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira