[
https://issues.apache.org/jira/browse/HBASE-22806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902600#comment-16902600
]
Terry Moschou commented on HBASE-22806:
---------------------------------------
{quote}Please try imagine your CF have billions of cells in production env,
it's an unacceptable to tomb every cells just after calling
Admin#deleteColumnFamily.
{quote}
My understanding is CFs are physically different files/directories on HDFS and
therefore a delete column family should be a simple HDFS atomic delete or
move/rename operation; tombing cells, I would think, should not be necessary -
is this not the case with HBase's implementation?
I will note that Google Bigtable [explicitly calls out|
[https://cloud.google.com/bigtable/docs/managing-tables#deleting_column_families]]
data from deleted column families are unrecoverable.
Does this have the potential for data, once protected by a column family scoped
ACL, to no longer be secure?
> Recreating a deleted column family brings back the deleted cells
> ----------------------------------------------------------------
>
> Key: HBASE-22806
> URL: https://issues.apache.org/jira/browse/HBASE-22806
> Project: HBase
> Issue Type: Bug
> Components: API
> Affects Versions: 2.1.3
> Environment: Scala
> HBase Java Client
> Mac/Linux
> Reporter: Chao
> Priority: Major
>
> Steps to reproduce the bug:
> # Create a table with column family CF
> # Add some cells C1, C2 in CF
> # Remove CF using either:
> ** TableDescriptorBuilder.removeColumnFamily() and Admin.modifyTable()
> ** Admin.deleteColumnFamily()
> # Create CF again
> Expected: no cells (all cells marked as deleted) in CF
> Actual: C1, C2 shows up automatically in CF
> Extra information: in step 3, if doing Admin.modifyColumnFamily() without
> actually changing anything, then after step 4 the cells won't come back.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
