Uploaded image for project: 'Phoenix'
  1. Phoenix
  2. PHOENIX-6491

Phoenix High Availability

    XMLWordPrintableJSON

Details

    • New Feature
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 5.2.0
    • core
    • None
    • Hide
      Phoenix HA feature to allow clients to connect to a pair of phoenix/hbase clusters in order to improve the overall availability for the supported use-cases.

      Supported use-cases:

      1. Active-Standby HA for disaster recovery, enables end users to switch HBase clusters (triggered by administrators) collectively across multiple clients without restarting.
      2. 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.
      Show
      Phoenix HA feature to allow clients to connect to a pair of phoenix/hbase clusters in order to improve the overall availability for the supported use-cases. Supported use-cases: 1. Active-Standby HA for disaster recovery, enables end users to switch HBase clusters (triggered by administrators) collectively across multiple clients without restarting. 2. 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.

    Description

      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:

      1. Active-Standby HA for disaster recovery, enables end users to switch HBase clusters (triggered by administrators) collectively across multiple clients without restarting.
      2. 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.

       

       

      Attachments

        Activity

          People

            dbwong Daniel Wong
            dbwong Daniel Wong
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: