Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 7 Dec 2015 10:01:11 +0000 (UTC)
From: "Phil Yang (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12841977.1435753971000.287977.1449482471019@Atlassian.JIRA>
In-Reply-To: <JIRA.12841977.1435753971000@Atlassian.JIRA>
References: <JIRA.12841977.1435753971000@Atlassian.JIRA>
 <JIRA.12841977.1435753971889@arcas>
Subject: [jira] [Commented] (HBASE-14004) [Replication] Inconsistency
 between Memstore and WAL may result in data in remote cluster that is not
 in the origin
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Phil Yang commented on HBASE-14004:
-----------------------------------

{quote}
Guess this may be the original design since there is TODO comments in FSHLog.java:
{quote}
If my understanding is right, these comments think we should truncate WAL file according to the position of the last synced log so we can avoid replaying or replicating edits that have been regarded as failed by clients. However, even if RS know where we should truncate. RS may crash after telling clients failing and before truncating. So I think there is a better idea that we do not truncate and only rewrite the logs to the new file and do not telling clients failing after we make WAL logging idempotent.

> [Replication] Inconsistency between Memstore and WAL may result in data in remote cluster that is not in the origin
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-14004
>                 URL: https://issues.apache.org/jira/browse/HBASE-14004
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>            Reporter: He Liangliang
>            Priority: Critical
>              Labels: replication, wal
>
> Looks like the current write path can cause inconsistency between memstore/hfile and WAL which cause the slave cluster has more data than the master cluster.
> The simplified write path looks like:
> 1. insert record into Memstore
> 2. write record to WAL
> 3. sync WAL
> 4. rollback Memstore if 3 fails
> It's possible that the HDFS sync RPC call fails, but the data is already  (may partially) transported to the DNs which finally get persisted. As a result, the handler will rollback the Memstore and the later flushed HFile will also skip this record.


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