[
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)
