Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Date: Mon, 6 Jul 2015 23:02:04 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: dev@hbase.apache.org
Message-ID: <JIRA.12843020.1436223710000.111910.1436223724707@Atlassian.JIRA>
In-Reply-To: <JIRA.12843020.1436223710000@Atlassian.JIRA>
References: <JIRA.12843020.1436223710000@Atlassian.JIRA>
 <JIRA.12843020.1436223710772@arcas>
Subject: [jira] [Created] (HBASE-14028) DistributedLogReplay drops edits
 when ITBLL 125M
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

stack created HBASE-14028:
-----------------------------

             Summary: DistributedLogReplay drops edits when ITBLL 125M
                 Key: HBASE-14028
                 URL: https://issues.apache.org/jira/browse/HBASE-14028
             Project: HBase
          Issue Type: Bug
          Components: Recovery
    Affects Versions: 1.2.0
            Reporter: stack


Testing DLR before 1.2.0RC gets cut, we are dropping edits.

Issue seems to be around replay into a deployed region that is on a server that dies before all edits have finished replaying. Logging is sparse on sequenceid accounting so can't tell for sure how it is happening (and if our now accounting by Store is messing up DLR). Digging.

I notice also that DLR does not refresh its cache of region location on error -- it just keeps trying till whole WAL fails.... 8 retries...about 30 seconds. We could do a bit of refactor and have the replay find region in new location if moved during DLR replay.


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