[ 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)