hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Helmling (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HBASE-1949) KeyValue expiration by Time-to-Live during major compaction is broken
Date Thu, 05 Nov 2009 17:03:32 GMT

     [ https://issues.apache.org/jira/browse/HBASE-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gary Helmling updated HBASE-1949:
---------------------------------

    Attachment: HBASE-1949-v2-0.20.patch

The previous version of this patch missed an additional case in QueryMatcher.match() -- called
from ScanFileGetScan -- which would exit early on a row for get requests when the first expired
KeyValue was encountered.  This would not actually remove data (like the previous occurance)
but would mask existing data from this client.

This version adds a change for the QueryMatcher.match() instance to return MatchCode.SKIP
instead of MatchCode.NEXT in order to keep processing any following kvs.

> KeyValue expiration by Time-to-Live during major compaction is broken
> ---------------------------------------------------------------------
>
>                 Key: HBASE-1949
>                 URL: https://issues.apache.org/jira/browse/HBASE-1949
>             Project: Hadoop HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 0.20.1
>            Reporter: Gary Helmling
>         Attachments: HBASE-1949-0.20.patch, HBASE-1949-trunk.patch, HBASE-1949-v2-0.20.patch,
HBASE-1949-v2-trunk.patch
>
>
> During a major compaction on a region in a column family with a configured TTL, it looks
like all KeyValues in a row after the first expired KeyValue are skipping and thrown out of
the newly written file (regardless of whether the would have been expired or not).
> The StoreScanner is skipping to the next row, even when other columns with a non-expirable
timestamp exists.  Unless I'm misunderstanding it, it seems like it should just seek to the
next column instead.  I discovered this when altering a table to lower the TTL for a column
family and force the expiration of some data which led to the entire row being expired in
some instances.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message