[
https://issues.apache.org/jira/browse/SENTRY-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalyan Kalvagadda resolved SENTRY-2445.
---------------------------------------
Resolution: Won't Fix
> Implement backup and restore mechanism for sentry permissions.
> --------------------------------------------------------------
>
> Key: SENTRY-2445
> URL: https://issues.apache.org/jira/browse/SENTRY-2445
> Project: Sentry
> Issue Type: New Feature
> Components: Sentry
> Reporter: Krishna Kalyan
> Assignee: Krishna Kalyan
> Priority: Major
> Fix For: 2.2.0
>
>
> Currently there is no proper story around backing up and restoring the
> sentry permission. This is very important feature which will help in
> mitigating issues caused because of loss of data.
> This should be working below scenarios.
> # Active-passive
> # Dual-active scenario
> *Active-passive scenario:* secondary cluster used only as a passive recovery
> cluster that is not activated until a datacenter disaster recovery event
> occurs. At failover, the secondary cluster activation occurs through manual,
> external intervention and is not automated by BDR.
> *Dual-active scenario:* Secondary cluster has equal capabilities as primary
> cluster.
> Data can be written to both clusters but a given table or directory can only
> be written on a single side. Replication can occur in both directions, but
> for a given table or directory, replication can only occur in a single
> direction. Users are expected to follow the organization’s read/write
> policies, e.g., write to a given table on the proper side; change Sentry
> permissions for a given table on the proper side. BDR will only provide
> enforcement in the case that if the DB schema that is being replicated is
> different on the destination site, the Hive import will fail, implying that
> Sentry permission import will not occur.
> * Let’s refer two active clusters as cluster-A and cluster-B. Permission
> information replicated from cluster-A to cluster-B is read only in cluster-B
> and vice versa. Let’s take an example: If the sentry replication is
> configured to replicate permission information for database “database1” from
> cluster-A to cluster-B, there should not be any permissions added/removed on
> that database(including the tables with in it) in cluster-B.
> *Backup Cluster:* There could be case customers use one cluster as backup
> cluster for all the other clusters they have. They should be able to a backup
> from all their cluster and restore it in their backup cluster periodically so
> that this backup cluster has a backup all the other clusters. This is
> possible only if the Hive data in each of the active cluster doesn't over lap.
> Sentry should have the capability to export permission information of all or
> selective databases/tables to a file in HDFS which is formatted in ini format.
> Sentry should be able to import permission information of all or selective
> databases/tables in a file in HDFS which is formatted in ini format.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
