You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@phoenix.apache.org by "Daniel Wong (Jira)" <ji...@apache.org> on 2022/04/27 22:49:00 UTC

[jira] [Commented] (PHOENIX-6491) Phoenix High Availability

    [ https://issues.apache.org/jira/browse/PHOENIX-6491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17529110#comment-17529110 ] 

Daniel Wong commented on PHOENIX-6491:
--------------------------------------

Initial WIP feature commit from our internal fork.  [https://github.com/apache/phoenix/pull/1430]

> Phoenix High Availability
> -------------------------
>
>                 Key: PHOENIX-6491
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-6491
>             Project: Phoenix
>          Issue Type: New Feature
>          Components: core
>            Reporter: Daniel Wong
>            Assignee: Daniel Wong
>            Priority: Major
>
> This JIRA proposes Phoenix High Availability (HA) feature which allows Phoenix users to interact with multiple Phoenix/HBase clusters in order to achieve additional availability compared to a single cluster. In particular we target the common deployment configuration of 2 HBase clusters with master/master asynchronous replication enabled between the queried tables, but with consideration to future extensions in use cases, replication, and number of clusters.
>  
>  Currently targeted use cases:
>  # Active-Standby HA for disaster recovery, enables end users to switch HBase clusters (triggered by administrators) collectively across multiple clients without restarting.
>  # Active-Active HA for immutable use cases with point get queries without deletes, enables a client to connect to both clusters simultaneously for these use cases which inherently have relaxed consistency requirements.
> Concepts:
>  * HA Group - An HA group is an association between a pair of HBase clusters, a group of Phoenix clients, metadata state, and an HA policy (see below). HA groups are pre-defined and a client provides the group name when creating a phoenix connection to the clusters in that HA group. Note that the same pair of HBase clusters can be in multiple HA groups. This allows clients to be grouped based on different use cases, availability requirements, consistency requirements, and load balancing.
>  * HA Policy - Every HA group has an associated HA policy which specifies how to use the HBase clusters pair. This is implemented by an interface that replaces the JDBC Connection as well as changes in the public APIs in QueryServices. Currently, there are 2 policies one for each targeted use case defined above. It is possible to support more HA policies in future for incoming use cases.
>  * Metadata Store - Stores the state / manages the state transitions of an HA group. For example in the Active-Standby setup the store manages which cluster is currently Active to which all clients in that HA group should connect. For a particular HA group an entry is referred to as a Cluster Role Record.
>  * HA Client - JDBC implementation as well as a handler for metadata store state changes. End users will use via PhoenixDriver with JDBC string with special format {{jdbc:phoenix:[zk1,zk2,zk3|zk1',zk2',zk3']}} and HA group name in the connection properties. Using such a JDBC connection for creating {{Statement}} or querying a {{ResultSet}} does not require any application code change. Internally, the implementation will serve incoming client operation requests according to the HA policy of that group.
> More details to come with a detailed design document.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)