[
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
(v6.1.5#6160)
