Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B07761801B for ; Wed, 9 Dec 2015 17:23:16 +0000 (UTC) Received: (qmail 17958 invoked by uid 500); 9 Dec 2015 17:23:11 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 17915 invoked by uid 500); 9 Dec 2015 17:23:11 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 17894 invoked by uid 99); 9 Dec 2015 17:23:11 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Dec 2015 17:23:11 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 3D5FE2C1F7C for ; Wed, 9 Dec 2015 17:23:11 +0000 (UTC) Date: Wed, 9 Dec 2015 17:23:11 +0000 (UTC) From: "stack (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: 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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-14004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15049009#comment-15049009 ] stack commented on HBASE-14004: ------------------------------- Not sure I understand the question. Replication reads the WAL in order and sends to the remote cluster all it has read in order. When it gets to the remote side, all should be 'applied' in order. How we get your scenarios #2, #3, etc., above? bq. In write path, some entries hflushed but not acked, so we close old WAL with acked length, and try to write this entries into new WAL, then RS crashed. Slave maybe has replicate this entries but RS after recovery in master will lost them, right? Isn't this essentially the description that leads off this JIRA? > [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)