[ https://issues.apache.org/jira/browse/HBASE-22938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16917749#comment-16917749 ]
Sean Busbey edited comment on HBASE-22938 at 8/28/19 12:53 PM: --------------------------------------------------------------- {quote} **Would this make recovery more difficult? (specifically the case where the meta table is out of wack) {quote} oh man. yeah. having recently dealt with a spat of clusters with meta truncated by an errant hbase 1.z OfflineMetaRepair, how do we rebuild e.g. the ACL information or the visibility label information if we lose meta. I guess ACL we just have meta repair write whatever is needed to have a valid set up that's only accessible to the super user. Visibility labels requires a walk of the hfiles? I hope we keep a dictionary per hfile, but I don't think we do. maybe automated TTL snapshots of hbase:meta is the way meta recoveries happen rather than trying to go from HDFS contents? was (Author: busbey): bq. **Would this make recovery more difficult? (specifically the case where the meta table is out of wack) oh man. yeah. having recently dealt with a spat of clusters with meta truncated by an errant hbase 1.z OfflineMetaRepair, how do we rebuild e.g. the ACL information or the visibility label information if we lose meta. I guess ACL we just have meta repair write whatever is needed to have a valid set up that's only accessible to the super user. Visibility labels requires a walk of the hfiles? I hope we keep a dictionary per hfile, but I don't think we do. maybe we automated TTL snapshots of hbase:meta is the way meta recoveries happen rather than trying to go from HDFS contents? > Fold all the system tables to hbase:meta > ---------------------------------------- > > Key: HBASE-22938 > URL: https://issues.apache.org/jira/browse/HBASE-22938 > Project: HBase > Issue Type: Brainstorming > Reporter: Duo Zhang > Priority: Major > > Quote my post on HBASE-15867 here, on how to deal with the dead lock when we > want to store replication queues to hbase:replication table. > {quote} > We could add a special prefix in the row key for different system tables, and > make a special family for it. For example, for all the records in hbase:acl, > we could introduce a prefix like ':::acl:::', since we do not allow ':' in > either namespace or table name, so it will not conflict with the existing > table related records. And the family could be namd as 'acl'. > And we could make a special split policy that only splits at these special > prefixs, so it will not break any assumptions so far, as all the records for > the 'system table' are in the same region. > {quote} > And I think there are also other advantages, for example the start up logic > can be greatly simplified. -- This message was sent by Atlassian Jira (v8.3.2#803003)