[
https://issues.apache.org/jira/browse/HBASE-10227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13869784#comment-13869784
]
Sergey Shelukhin commented on HBASE-10227:
------------------------------------------
RB would be nice.
Storing mvcc in store file always is an interesting option.
However, it becomes unnecessary for most KVs after some time under current
HBase assumptions (that storefiles can be compared, all KVs in one SF are older
than all KVs in the other per seqId/mvcc).
The only uses for mvcc in KV at that point is exact same key in the file, and
scanners, but the latter need disappears after some time, see some later
comments in HBASE-10244.
Some minor comments on the patch:
bq. mvcc.reinitialize(maxMemstoreTS + 1);
is now called twice in the same place.
With removal of usage performCompaction no longer needs smallestReadPoint.
Also parameter might not be necessary in createWriterInTmp
Ok this is major comment.
bq. if (versionOrLength == VERSION_3) {
Is it possible to add MVCCs from corresponding KVs to protobuf part, rather
than expand WALEdit format?
I think the proper way is actually to make mvcc serialization a "first class"
part of KV, there's JIRA for that; but that might be too much for this patch,
as it would require new HFile version.
For now we can at least avoid more hard-to-maintain-compat stuff down the line.
Already, it appears that old reader will not read V_3 correctly.
> 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: Feng Honghua
> Attachments: HBASE-10227-trunk_v0.patch
>
>
> 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)
