phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Kyle Purtell (Jira)" <>
Subject [jira] [Assigned] (PHOENIX-5520) Phoenix-level HBase ReplicationEndpoint
Date Wed, 22 Jan 2020 23:47:00 GMT


Andrew Kyle Purtell reassigned PHOENIX-5520:

    Assignee: Bharath Vissapragada

> Phoenix-level HBase ReplicationEndpoint
> ---------------------------------------
>                 Key: PHOENIX-5520
>                 URL:
>             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

View raw message