[ 
https://issues.apache.org/jira/browse/HBASE-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-14949:
------------------------------
    Description: The AsyncFSHLog introduced in HBASE-14790 may write same WAL 
entries to different WAL files. WAL entry itself is idempotent so replay is not 
a problem but the intermediate file name and final name when splitting is 
constructed using the lowest or highest sequence id of the WAL entries written, 
so it is possible that different WAL files will have same intermediate or final 
file name when splitting. In the currentm implementation, this will cause split 
fail or data loss. We need to solve this.  (was: As HBASE-14004 design,  there 
will be duplicate entries in different WAL.  It happens when one hflush failed, 
we will close old WAL with 'acked hflushed' length,  then open a new WAL and 
write the unacked hlushed entries into it.
So there maybe some overlap between old WAL and new WAL.

We should skip the duplicate entries when replay.  I think it has no harm to 
current logic, maybe we do it first. )

> Resolve name conflict when splitting if there are duplicated WAL entries
> ------------------------------------------------------------------------
>
>                 Key: HBASE-14949
>                 URL: https://issues.apache.org/jira/browse/HBASE-14949
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Heng Chen
>            Assignee: Duo Zhang
>         Attachments: HBASE-14949-v3.patch, HBASE-14949.patch, 
> HBASE-14949_v1.patch, HBASE-14949_v2.patch
>
>
> The AsyncFSHLog introduced in HBASE-14790 may write same WAL entries to 
> different WAL files. WAL entry itself is idempotent so replay is not a 
> problem but the intermediate file name and final name when splitting is 
> constructed using the lowest or highest sequence id of the WAL entries 
> written, so it is possible that different WAL files will have same 
> intermediate or final file name when splitting. In the currentm 
> implementation, this will cause split fail or data loss. We need to solve 
> this.



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

Reply via email to