hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-13811) Splitting WALs, we are filtering out too many edits -> DATALOSS
Date Tue, 02 Jun 2015 23:13:50 GMT

     [ https://issues.apache.org/jira/browse/HBASE-13811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

stack updated HBASE-13811:
--------------------------
    Attachment: 13811.txt

Mostly logging changes so we output less but with more density including detail like sequence
id at critical junctures so it easier debugging these issues going forward. Patch includes
a change log.  Fix is in FSHLog getEarliestMemstoreSeqNum methods; look in the Map of currently
flushing sequence ids first and then if none found here, look in the oldest sequence id map.

Trying this patch against hadoopqa to see if I've broke anything. Trying on a cluster. Need
to add a test for this particular case still.


> 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
>            Reporter: stack
>            Priority: Critical
>         Attachments: 13811.txt
>
>
> 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)

Mime
View raw message