hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yu Li (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17471) Region Seqid will be out of order in WAL if using mvccPreAssign
Date Thu, 19 Jan 2017 07:02:26 GMT

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

Yu Li commented on HBASE-17471:

+1 on the fix. IIRC, [~enis] also mentioned not to include any configuration and make preassign
the logic if it indeed improves performance, but I'm not quite sure whether it's true for
append/increment in real world (though in theory I believe in this), so I guess more test
and data need to be supplied.

I'm leaving HBASE-16698 open (sorry for a quite long time I'd say...) because I see some unstable
performance number for ASYNC_WAL testing but didn't get time to confirm it later on. I guess
you've done more testing in your environment [~allan163]? If so, mind share the data here?

And have to admit that in our product scenarios we don't use any of append/increment request,
so I didn't think of the problem described here. Thanks for pointing out the issue and trying
hard to complete the work [~allan163].

> Region Seqid will be out of order in WAL if using mvccPreAssign
> ---------------------------------------------------------------
>                 Key: HBASE-17471
>                 URL: https://issues.apache.org/jira/browse/HBASE-17471
>             Project: HBase
>          Issue Type: Bug
>          Components: wal
>    Affects Versions: 2.0.0, 1.4.0
>            Reporter: Allan Yang
>            Assignee: Allan Yang
>            Priority: Critical
>         Attachments: HBASE-17471.patch, HBASE-17471.tmp
>  mvccPreAssign was brought by HBASE-16698, which truly improved the performance of writing,
especially in ASYNC_WAL scenario. But mvccPreAssign was only used in {{doMiniBatchMutate}},
not in Increment/Append path. If Increment/Append and batch put are using against the same
region in parallel, then seqid of the same region may not monotonically increasing in the
WAL. Since one write path acquires mvcc/seqid before append, and the other acquires in the
append/sync consume thread.
> The out of order situation can easily reproduced by a simple UT, which was attached in
the attachment. I modified the code to assert on the disorder: 
> {code}
>     if(this.highestSequenceIds.containsKey(encodedRegionName)) {
>       assert highestSequenceIds.get(encodedRegionName) < sequenceid;
>     }
> {code}
> I'd like to say, If we allow disorder in WALs, then this is not a issue. 
> But as far as I know, if {{highestSequenceIds}} is not properly set, some WALs may not
archive to oldWALs correctly.
> which I haven't figure out yet is that, will disorder in WAL cause data loss when recovering
from disaster? If so, then it is a big problem need to be fixed.
> I have fix this problem in our costom1.1.x branch, my solution is using mvccPreAssign
everywhere, making it un-configurable. Since mvccPreAssign it is indeed a better way than
assign seqid in the ringbuffer thread while keeping handlers waiting for it.
> If anyone think it is doable, then I will port it to branch-1 and master branch and upload

This message was sent by Atlassian JIRA

View raw message