hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duo Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14004) [Replication] Inconsistency between Memstore and WAL may result in data in remote cluster that is not in the origin
Date Mon, 18 Sep 2017 06:17:04 GMT

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

Duo Zhang commented on HBASE-14004:
-----------------------------------

The problem for FSHLog is complicated. One thing is that, syncing WAL is also an IPC, so a
timeout does not mean fail, it's just unknown. But when syncing failed, we will just fail
the log request and the upper layer will treat it as a failure which means the memstore will
not be modified. I think this is much easier to happen than the scenario described in the
above doc, so, this patch is a nice to have for branch-1, but there are still a lot of works
to do for FSHLog...

Thanks.

> [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, Replication
>            Reporter: He Liangliang
>            Assignee: Duo Zhang
>            Priority: Critical
>              Labels: replication, wal
>             Fix For: 3.0.0, 2.0.0-alpha-4
>
>         Attachments: HBASE-14004.patch, HBASE-14004-v1.patch, HBASE-14004-v2.patch, HBASE-14004-v2.patch,
HBASE-14004-v3.patch
>
>
> 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 is a long lived issue. The above problem is solved by write path reorder, as now
we will sync wal first before modifying memstore. But the problem may still exists as replication
thread may read the new data before we return from hflush. See this document for more details:
> https://docs.google.com/document/d/11AyWtGhItQs6vsLRIx32PwTxmBY3libXwGXI25obVEY/edit#
> So we need to keep a sync length in WAL and tell replication wal reader this is limit
when you read this wal file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message