hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14949) Resolve name conflict when splitting if there are duplicated WAL entries
Date Wed, 17 Feb 2016 17:24:18 GMT

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

stack commented on HBASE-14949:
-------------------------------

bq.  I think we could change it to private.

Go for it.

bq, No, I just append the file name after the result of formatRecoveredEditsFileName...

But does other use o formatRecoveredEditsFileName need filename added too?

bq. We only change the intermediate tmp file name, it will be renamed when split end. 

I see. Ignore my question then. Thanks.

Can make private on commit and if my question on use of formatRecoveredEditsFileName from
other context has simple answer, this patch is good to go. +1.


> 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-v4.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)

Mime
View raw message