Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 2 Dec 2016 05:35:58 +0000 (UTC)
From: "Duo Zhang (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13023512.1480171301000.420405.1480656958490@Atlassian.JIRA>
In-Reply-To: <JIRA.13023512.1480171301000@Atlassian.JIRA>
References: <JIRA.13023512.1480171301000@Atlassian.JIRA> <JIRA.13023512.1480171301025@arcas>
Subject: [jira] [Commented] (HBASE-17177) Major compaction can break the
 region/row level atomic when scan even if we pass mvcc to client
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 02 Dec 2016 05:36:00 -0000


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

Duo Zhang commented on HBASE-17177:
-----------------------------------

{quote}
Not sure about NONE/ROW/REGION. Can we do REGION first, since mvcc is by region, and then if needed do ROW and NONE.
{quote}

NONE/ROW/REGION is the lower bound, if there is no error then we will always have the REGION level atomicity. The problem only happens when there is an error and we need to reopen a scanner. We will try our best to keep the REGION level atomicity but as said above, we can not always succeed. And if the bad things happen, then we will use the 'atomicity' option to determine if we can go on or throw an exception to user.

Thanks.

> Major compaction can break the region/row level atomic when scan even if we pass mvcc to client
> -----------------------------------------------------------------------------------------------
>
>                 Key: HBASE-17177
>                 URL: https://issues.apache.org/jira/browse/HBASE-17177
>             Project: HBase
>          Issue Type: Sub-task
>          Components: scan
>            Reporter: Duo Zhang
>             Fix For: 2.0.0, 1.4.0
>
>
> We know that major compaction will actually delete the cells which are deleted by a delete marker. In order to give a consistent view for a scan, we need to use a map to track the read points for all scanners for a region, and the smallest one will be used for a compaction. For all delete markers whose mvcc is greater than this value, we will not use it to delete other cells.
> And the problem for a scan restart after region move is that, the new RS does not have the information of the scanners opened at the old RS before the client sends scan requests to the new RS which means the read points map is incomplete and the smallest read point maybe greater than the correct value. So if a major compaction happens at that time, it may delete some cells which should be kept.


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