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

stack commented on HBASE-13811:
-------------------------------

If I make this change:

{code}
diff --git 
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
index dc3f4b5..4496a59 100644
--- 
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
+++ 
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
@@ -2157,7 +2157,7 @@ public class HRegion implements HeapSize, 
PropagatingConfigurationObserver, Regi
               myseqid);
           }
           flushOpSeqId = getNextSequenceId(wal);
-          flushedSeqId = getFlushedSequenceId(encodedRegionName, flushOpSeqId);
+          flushedSeqId = flushOpSeqId;// 
getFlushedSequenceId(encodedRegionName, flushOpSeqId);
         } else {
           // use the provided sequence Id as WAL is not being used for this 
flush.
           flushedSeqId = flushOpSeqId = myseqid;
{code}

The test in its old form passes.

Let me think about it:

+ Relying on the flushid seems wrong but that is how it used to be.
+ It seems more true reporting the one-before the current oldest edit in 
memstore as the place to restart the replay

Let me look more.

Thanks [~Apache9]

> Splitting WALs, we are filtering out too many edits -> DATALOSS
> ---------------------------------------------------------------
>
>                 Key: HBASE-13811
>                 URL: https://issues.apache.org/jira/browse/HBASE-13811
>             Project: HBase
>          Issue Type: Bug
>          Components: wal
>    Affects Versions: 2.0.0, 1.2.0
>            Reporter: stack
>            Assignee: stack
>            Priority: Critical
>             Fix For: 2.0.0, 1.2.0
>
>         Attachments: 13811.branch-1.txt, 13811.branch-1.txt, 13811.txt, 
> HBASE-13811-v1.testcase.patch, HBASE-13811.testcase.patch
>
>
> I've been running ITBLLs against branch-1 around HBASE-13616 (move of 
> ServerShutdownHandler to pv2). I have come across an instance of dataloss. My 
> patch for HBASE-13616 was in place so can only think it the cause (but cannot 
> see how). When we split the logs, we are skipping legit edits. Digging.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to