[
https://issues.apache.org/jira/browse/HBASE-13811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14572388#comment-14572388
]
Duo Zhang commented on HBASE-13811:
-----------------------------------
{quote}
I just set it to the flush sequenceid
{quote}
I think this would fail
TestPerColumnFamilyFlush.testLogReplayWithDistributedLogSplit?
The logic here should be
1. If we flush all stores or the unflushed stores are all empty, then just use
flushOpSeqId.
2. Else, find the lowest seqId of the edits in unflushed stores and then minus
1.
The original version of getEarliestMemstoreSeqNum can just fit into the logic,
but it will cause data loss as described above. So I think we still need the
original version of getEarliestMemstoreSeqNum, but we can rename it to more
suitable name? Maybe calcFlushedSeqId? Thanks.
> 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,
> 13811.v2.branch-1.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)
