[ https://issues.apache.org/jira/browse/HBASE-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119932#comment-13119932 ]
Lars Hofhansl commented on HBASE-4536: -------------------------------------- There's a fourth scan type: 4. Memstore flush (see HBASE-4241). This behaves exactly like #2. There is a pathetic scenario where CF has minversions set and a client only write delete markers. As they are not counted as versions, they would never be removed (not even in a major compaction). I suppose to guard against that case we could remove all trailing delete markers (that are not followed by any surviving kvs). > Allow CF to retain deleted rows > ------------------------------- > > Key: HBASE-4536 > URL: https://issues.apache.org/jira/browse/HBASE-4536 > Project: HBase > Issue Type: Sub-task > Components: regionserver > Affects Versions: 0.92.0 > Reporter: Lars Hofhansl > Assignee: Lars Hofhansl > Fix For: 0.92.0, 0.94.0 > > > Parent allows for a cluster to retain rows for a TTL or keep a minimum number > of versions. > However, if a client deletes a row all version older than the delete tomb > stone will be remove at the next major compaction (and even at memstore flush > - see HBASE-4241). > There should be a way to retain those version to guard against software error. > I see two options here: > 1. Add a new flag HColumnDescriptor. Something like "RETAIN_DELETED". > 2. Folds this into the parent change. I.e. keep minimum-number-of-versions of > versions even past the delete marker. > #1 would allow for more flexibility. #2 comes somewhat naturally with parent > (from a user viewpoint) > Comments? Any other options? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira