w.r.t. hbase.store.delete.expired.storefile, I checked hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java in 0.98 branch and branch-1 Default value is true.
FYI On Wed, Mar 11, 2015 at 3:12 PM, Alex Baranau <[email protected]> wrote: > Expired rows are also deleted on minor compaction. But, depending on the > distribution of the writes you may have some regions that don't get any > writes and hence their files will stay in "frozen" state without any > compaction being triggerred on them, until major compaction is fired for > that specific region or the whole table. Given that you reclaimed only a > bit of space - part of that could be due to this.. > > http://hbase.apache.org/book.html#ttl also > mentions hbase.store.delete.expired.storefile config property - be sure to > have it as true to delete the whole store files (unless files are deleted, > they occupy space in hdfs). > > Alex Baranau > > http://cdap.io - open source framework to build and run data applications > on > Hadoop & HBase > > On Tue, Mar 10, 2015 at 9:15 PM, David chen <[email protected]> wrote: > > > Thanks lars, > > I ever ran scan to test TTL for several times, the data expired could > not > > be seen. > > In my application scene, the capacity of everyday collecting data should > > be almost similar. so the new collecting data should not be more than the > > data expired. > > Following your way, I forced a major compaction this morning, the space > > reduced from 946G to 924G. > > In order to reclaim the expired space, must force the major compaction? >
