src/main/docbkx/security.xml | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/src/main/docbkx/security.xml b/src/main/docbkx/security.xml index 61493cd..bca63a0 100644 --- a/src/main/docbkx/security.xml +++ b/src/main/docbkx/security.xml @@ -1414,6 +1414,31 @@ static HTable createTableAndWriteDataWithLabels(TableName tableName, String... l can also configure a set of ScanLabelGenerators to be used by the system, as a comma-separated list. +
+ Replicating visibility tags as strings + As mentioned in the above sections, the interface VisibilityLabelService could + be used to implement the way the visibility expressions can be stored in the cells. When we have clusters + with replication we also require that the visibility expressions are also replicated to the peer cluster. + Take the case where the DefaultVisibilityLabelServiceImpl is used as the implementation for + VisibilityLabelService. All the visibility expression are converted to the corresponding + ordinal based expression based on the ordinals for each visibility label stored in the labels table. This + would mean that during replication the cells with visibility would also be replicated with ordinal based + expression. In the peer cluster, we may not have the same labels table with the same ordinal mapping for + the visibility labels. In that case the ordinals in the replicated cell does not make sense. + Hence it would be better if the replication happens with the visibility expression as strings. + In order to replicate the visibility expression as strings to the peer cluster we have a RegionServerObserver + configuration which would work based on the implementation of the interface VisibilityLabelService. + Use the below configuration to configure replication of visibility expressions to peer cluster as strings. See + for more details. + + + hbase.coprocessor.regionserver.classes + org.apache.hadoop.hbase.security.visibility.VisibilityController$VisibilityReplication + + ]]> +