[
https://issues.apache.org/jira/browse/HBASE-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149549#comment-15149549
]
stack commented on HBASE-14949:
-------------------------------
TestMasterStatusServlet has been fixed and TestRegionMergeTransactionOnCluster
is being dealt with as a flakey elsewhere.
So we append the name of the file-being-split to the recovered edits file name?
This works because original WAL is named in timestamp-increasing order?
We should never call deleteOneWithFewerEntries when the above new naming
mechanism is in place?
We still need the migration switch to not use new naming convention until
cluster is all up on new code? If so, lets file issue for it as blocker on 2.0.
If we do find two files the same, we just take the one with most edits without
regard to sequenceids?
Nice test.
Thanks.
> 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)
