palashc commented on code in PR #21: URL: https://github.com/apache/phoenix-site/pull/21#discussion_r3268942844
########## app/pages/_docs/docs/_mdx/(multi-page)/features/high-availability.mdx: ########## @@ -0,0 +1,187 @@ +--- +title: "High Availability" +description: "Active/active and active/standby Phoenix client wiring across two HBase clusters, with graceful failover that lets in-flight readers drain while writes are blocked." +--- + +Phoenix High Availability (HA) lets a JDBC client transparently target a pair +of HBase clusters that mirror the same Phoenix schema, so an operator-driven +or fault-driven failover never requires the application to restart, reconnect, +or rewrite URLs. + +Phoenix 5.3.1 adds **graceful failover** — an intermediate `ACTIVE_TO_STANDBY` +role that lets writes drain while readers keep working — plus support for +HBase's `MASTER` and `RPC` connection registries +([PHOENIX-7493](https://issues.apache.org/jira/browse/PHOENIX-7493), +[PHOENIX-7495](https://issues.apache.org/jira/browse/PHOENIX-7495), +[PHOENIX-7586](https://issues.apache.org/jira/browse/PHOENIX-7586)). + +## Concepts [#ha-concepts] + +An **HA group** is a named tuple of two HBase clusters and an HA policy, +shared by every client that participates. The current role of each cluster +lives in a JSON record in ZooKeeper, replicated to both clusters' ZK +ensembles and watched by the client; role changes are picked up +automatically. + +### Cluster roles + +| Role | Clients can connect? | Meaning | +| ------------------- | :------------------: | ------------------------------------------------------------------------------------------------------------------------------------- | +| `ACTIVE` | yes | Cluster is serving live reads and writes. | +| `STANDBY` | yes | Cluster is reachable but not the current primary; FAILOVER clients refuse to bind to it. | +| `ACTIVE_TO_STANDBY` | yes | Transitional state during graceful failover: existing readers continue to work; writes may be rejected (see Graceful failover below). | +| `OFFLINE` | no | Cluster is intentionally taken out of rotation. | +| `UNKNOWN` | no | Role has not been initialized or the record could not be read. | + +### HA policies + +The policy is part of the HA-group record. Clients do not pick it — operators +do, when provisioning the group. + +- **`FAILOVER`** — exactly one cluster (the `ACTIVE`) serves the connection at + any moment. The client transparently re-binds on role change. +- **`PARALLEL`** — every statement is issued to **both** clusters in parallel, + with the faster result returned. Useful when both clusters carry identical + data and you want to mask single-cluster tail latency. + +### Failover sub-policies (FAILOVER only) + +Controls how a FAILOVER connection reacts when its bound cluster transitions +away from `ACTIVE`: + +| `phoenix.ha.failover.policy` | Behavior | +| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | +| `explicit` (default) | Subsequent operations throw `FailoverSQLException`; the application calls `failover()` to rebind to the new `ACTIVE`. | +| `active` | Connection transparently rebinds to the new `ACTIVE` on the next statement, up to `phoenix.ha.failover.count` attempts (default `3`). | Review Comment: > haven't used active policy at SFDC that should be okay, this is for open source website and if the feature supports it, we can add it ########## app/pages/_docs/docs/_mdx/(multi-page)/features/high-availability.mdx: ########## @@ -0,0 +1,187 @@ +--- +title: "High Availability" +description: "Active/active and active/standby Phoenix client wiring across two HBase clusters, with graceful failover that lets in-flight readers drain while writes are blocked." +--- + +Phoenix High Availability (HA) lets a JDBC client transparently target a pair +of HBase clusters that mirror the same Phoenix schema, so an operator-driven +or fault-driven failover never requires the application to restart, reconnect, +or rewrite URLs. + +Phoenix 5.3.1 adds **graceful failover** — an intermediate `ACTIVE_TO_STANDBY` +role that lets writes drain while readers keep working — plus support for +HBase's `MASTER` and `RPC` connection registries +([PHOENIX-7493](https://issues.apache.org/jira/browse/PHOENIX-7493), +[PHOENIX-7495](https://issues.apache.org/jira/browse/PHOENIX-7495), +[PHOENIX-7586](https://issues.apache.org/jira/browse/PHOENIX-7586)). + +## Concepts [#ha-concepts] + +An **HA group** is a named tuple of two HBase clusters and an HA policy, +shared by every client that participates. The current role of each cluster +lives in a JSON record in ZooKeeper, replicated to both clusters' ZK +ensembles and watched by the client; role changes are picked up +automatically. + +### Cluster roles + +| Role | Clients can connect? | Meaning | +| ------------------- | :------------------: | ------------------------------------------------------------------------------------------------------------------------------------- | +| `ACTIVE` | yes | Cluster is serving live reads and writes. | +| `STANDBY` | yes | Cluster is reachable but not the current primary; FAILOVER clients refuse to bind to it. | +| `ACTIVE_TO_STANDBY` | yes | Transitional state during graceful failover: existing readers continue to work; writes may be rejected (see Graceful failover below). | +| `OFFLINE` | no | Cluster is intentionally taken out of rotation. | +| `UNKNOWN` | no | Role has not been initialized or the record could not be read. | + +### HA policies + +The policy is part of the HA-group record. Clients do not pick it — operators +do, when provisioning the group. + +- **`FAILOVER`** — exactly one cluster (the `ACTIVE`) serves the connection at + any moment. The client transparently re-binds on role change. +- **`PARALLEL`** — every statement is issued to **both** clusters in parallel, + with the faster result returned. Useful when both clusters carry identical + data and you want to mask single-cluster tail latency. + +### Failover sub-policies (FAILOVER only) + +Controls how a FAILOVER connection reacts when its bound cluster transitions +away from `ACTIVE`: + +| `phoenix.ha.failover.policy` | Behavior | +| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | +| `explicit` (default) | Subsequent operations throw `FailoverSQLException`; the application calls `failover()` to rebind to the new `ACTIVE`. | +| `active` | Connection transparently rebinds to the new `ACTIVE` on the next statement, up to `phoenix.ha.failover.count` attempts (default `3`). | Review Comment: > haven't used active policy at SFDC @lokiore that should be okay, this is for open source website and if the feature supports it, we can add it -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
