[
https://issues.apache.org/jira/browse/PHOENIX-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021626#comment-17021626
]
Geoffrey Jacoby commented on PHOENIX-5520:
------------------------------------------
[~bharathv] - it's OK if this just goes into the 4.x branches initially, and
gets "forward-ported" to master later. There are already a few features like
that in Phoenix because of compatibility issues like this one.
> Phoenix-level HBase ReplicationEndpoint
> ---------------------------------------
>
> Key: PHOENIX-5520
> URL: https://issues.apache.org/jira/browse/PHOENIX-5520
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Geoffrey Jacoby
> Assignee: Bharath Vissapragada
> Priority: Major
>
> A Phoenix implementation of HBase's ReplicationEndpoint that tails the WAL
> like a normal replication endpoint. However, rather than writing to HBase's
> replication sink APIs (which create HBase RPCs to a remote cluster), they
> should write to a new Phoenix Endpoint coprocessor (created in a separate
> sub-task).
> This assumes that the WAL entries have been annotated with Phoenix metadata
> (tenant, logical table/view name, timestamp) using the mechanism in
> PHOENIX-5435.
> While many custom ReplicationEndpoints inherit from
> HBaseInterClusterReplicationEndpoint and just override the filtering logic,
> this will need to avoid HBaseInterClusterReplicationEndpoint (which uses
> HBase RPCs and the HBase sink manager) and instead inherit from
> BaseReplicationEndpoint, or even implement the ReplicationEndpoint interface
> + extend AbstractService directly. This is because it has to manage its own
> transport mechanism to the remote cluster.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
