[
https://issues.apache.org/jira/browse/PHOENIX-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021624#comment-17021624
]
Andrew Kyle Purtell commented on PHOENIX-5520:
----------------------------------------------
bq. I think one solution is to prototype on branch 4.15-HBase-1.5
Make a feature branch based on 4.15-HBase-1.5, do your dev there, then merge
from feature branch when ready - done!
> 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)
