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
+
+ ]]>
+