[
https://issues.apache.org/jira/browse/PHOENIX-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873651#comment-16873651
]
Geoffrey Jacoby commented on PHOENIX-3939:
------------------------------------------
Filed this a couple of years ago to contribute a ReplicationEndpoint we use
quite a bit at my employer. It's proven non-trivial to create a version of
Tenant-based replication that's completely free of assumptions specific to my
employer.
The big assumptions are:
1. Character length of a tenantId (used when parsing tenantIds out of view
indexes)
2. The notion of "implicit multi-tenancy" -- that even if a table does not have
an explicit MULTI_TENANT=true flag, it should also be treated as multi-tenant
for purposes of replication if the row key contains a column that matches a
known naming convention.
The first can probably be worked around; the second requires PHOENIX-5249 (or
to fork the existing code and remove the implicit multi-tenancy logic).
> Tenant-based Replication
> ------------------------
>
> Key: PHOENIX-3939
> URL: https://issues.apache.org/jira/browse/PHOENIX-3939
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Major
>
> Standard HBase replication offers a few ways to control what subset of a
> cluster's data gets replicated to a replication peer, generally by table and
> column family. However, there's no way for a multi-tenant cluster to say
> "these tenants will replicate to this peer, and these other tenants will be
> replicated to a different peer, and this third group will not be replicated
> at all."
> Phoenix's first-class multi-tenant and composite key support makes this
> possible. This feature will create a new optional replication plugin,
> "TenantReplicationEndpoint", and a new optional Phoenix system table to store
> tenant/target cluster mappings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
