[
https://issues.apache.org/jira/browse/PHOENIX-6491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated PHOENIX-6491:
----------------------------------
Fix Version/s: 5.2.0
> 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
> Fix For: 5.2.0
>
>
> 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.
> Not Supported:
> Multiple Kerberos Authentication, each cluster must use the same auth.
> This could be addressed in a future release.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
