hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Feng Honghua (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10227) When a region is opened, its mvcc isn't correctly recovered when there are split hlogs to replay
Date Sat, 28 Dec 2013 15:04:52 GMT

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

Feng Honghua commented on HBASE-10227:

[~gustavoanatoly] : glad to know you're also aware of this bug and show interest for fixing
it. :-)

Actually this issue had already been fixed in my patch for JIRA-8721 (where the mvcc can't
be set zero and need to keep across region move / regionserver failover / balance etc, I noticed
and fixed this 'logic' bug as a part of that patch), since JIRA-8721 experienced several times
close/reopen/close, I think it's not a good timing to reopen it again. but the exposing of
this bug and providing its fix can be opened as a separate JIRA.

If you can't schedule time for this fix, maybe I can re-assign to myself and extract the fix
for this bug from JIRA-8721's patch to here for discussion/review, what do you think? [~gustavoanatoly]
/ [~stack]

> When a region is opened, its mvcc isn't correctly recovered when there are split hlogs
to replay
> ------------------------------------------------------------------------------------------------
>                 Key: HBASE-10227
>                 URL: https://issues.apache.org/jira/browse/HBASE-10227
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>            Reporter: Feng Honghua
>            Assignee: Gustavo Anatoly
> When opening a region, all stores are examined to get the max MemstoreTS and it's used
as the initial mvcc for the region, and then split hlogs are replayed. In fact the edits in
split hlogs have kvs with greater mvcc than all MemstoreTS in all store files, but replaying
them don't increment the mvcc according at all. From an overall perspective this mvcc recovering
is 'logically' incorrect/incomplete.
> Why currently it doesn't incur problem is because no active scanners exists and no new
scanners can be created before the region opening completes, so the mvcc of all kvs in the
resulted hfiles from hlog replaying can be safely set to zero. They are just treated as kvs
put 'earlier' than the ones in HFiles with mvcc greater than zero(say 'earlier' since they
have mvcc less than the ones with non-zero mvcc, but in fact they are put 'later'), and without
any incorrect impact just because during region opening there are no active scanners existing
/ created.
> This bug is just in 'logic' sense for the time being, but if later on we need to survive
mvcc in the region's whole logic lifecycle(across regionservers) and never set them to zero,
this bug needs to be fixed first.

This message was sent by Atlassian JIRA

View raw message