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

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

I have revised the doc 
https://docs.google.com/document/d/1tTwXrip18qxxsSiPu_y4fGB-26SxqwMvZnFREswyQow/edit?usp=sharing
 which removes the logic about hsync.

And previously the doc quotes Duo's comment
{quote}
close old file using any length that larger than the previous succeeded 
hflushed length
{quote}
I changed this to close the file using the previous succeeded hflushed length 
which is more clear for implementation.

And in section "Some issues still need discussion" I quote [~carp84]'s comment:
{quote}
We also need to consider the cross-RS case when region assign happens before 
wal sync acked.
{quote}
Yu, is it still a problem after we not using hsync?


> [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)

Reply via email to