hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Antonov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17887) Row-level consistency is broken for read
Date Sun, 14 May 2017 11:04:05 GMT

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

Mikhail Antonov commented on HBASE-17887:

Sorry, had quite busy week and just getting to this.

 - This is awful indeed.. thanks [~chia7712] for all investigation and fix!
 - Answering the question "should it go to 1.3.* line" - yeah, totally, as HBASE-14970 went
in 1.3.0. Did we move the "official" stable pointer to 1.3 yet? I don't remember vote on that..I
think we wanted to do it when 1.3.1 was going to be out, but we didn't? I think I can start
rolling 1.3.2 RCs for that in the coming week.

[~larsh] (cc [~apurtell])  regarding HBASE-13082, since you touched on that...:) As I recall,
it was a major pain point during initial 1.3 testing. [~ghelmling] has done a lot of great
work tracking down and fixing at least 2-3 critical regressions where there were races leading
to incorrect compacted files accounting (-> RS crashes). I considered reverting it from
1.3, but this change was committed to branch-1 long, long ago (and before 1.3 was cut, I believe)
..so reverting it was deemed quite non-trivial work. I think reverting it from 1.3 isn't the
best option now. We need to roll forward at this point.

Regarding possible other issues this change might have caused - HBASE-17406 is still open,
though I wasn't able to get a clear repro.

> Row-level consistency is broken for read
> ----------------------------------------
>                 Key: HBASE-17887
>                 URL: https://issues.apache.org/jira/browse/HBASE-17887
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 2.0.0, 1.3.0
>            Reporter: Umesh Agashe
>            Assignee: Chia-Ping Tsai
>            Priority: Blocker
>             Fix For: 2.0.0, 1.4.0, 1.3.2
>         Attachments: HBASE-17887.branch-1.v0.patch, HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch,
HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v3.patch,
HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch,
HBASE-17887.branch-1.v5.patch, HBASE-17887.branch-1.v6.patch, HBASE-17887.ut.patch, HBASE-17887.v0.patch,
HBASE-17887.v1.patch, HBASE-17887.v2.patch, HBASE-17887.v3.patch, HBASE-17887.v4.patch, HBASE-17887.v5.patch,
> The scanner of latest memstore may be lost if we make quick flushes. The following step
may help explain this issue.
> # put data_A (seq id = 10, active store data_A and snapshots is empty)
> # snapshot of 1st flush (active is empty and snapshot stores data_A)
> # put data_B (seq id = 11, active store data_B and snapshot store data_A)
> # create user scanner (read point = 11, so It should see the data_B)
> # commit of 1st flush
> #* clear snapshot ((hfile_A has data_A, active store data_B, and snapshot is empty)
> #* update the reader (the user scanner receives the hfile_A)
> # snapshot of 2st flush (active is empty and snapshot store data_B)
> # commit of 2st flush
> #* clear snapshot (hfile_A has data_A, hfile_B has data_B, active is empty, and snapshot
is empty) – this is critical piece.
> #* -update the reader- (haven't happen)
> # user scanner update the kv scanners (it creates scanner of hfile_A but nothing of memstore)
> # user see the older data A – wrong result

This message was sent by Atlassian JIRA

View raw message