LATEST VERSION: 2.5 - RELEASE NOTES

MySQL Proxy (HA Cluster)

Page last updated:

WARNING: Highly available (HA) cluster service plans are currently in beta. HA clusters are for advanced use cases only.

MySQL for Pivotal Cloud Foundry (PCF) uses a proxy to send client connections to the healthy MySQL database cluster nodes in a highly available (HA) cluster plan. Using a proxy gracefully handles failure of nodes, enabling fast, failover to other nodes within the cluster. When a node becomes unhealthy, the proxy closes all connections to the unhealthy node and re-routes all subsequent connections to a healthy node.

The proxy used in MySQL for PCF is Switchboard. Switchboard was developed to replace HAProxy as the proxy tier for the HA cluster for MySQL databases in PCF.

Switchboard offers the following features:

  • MySQL Server Access

    MySQL clients communicate with nodes through this network port. These connections are automatically passed through to the nodes.

  • Switchboard and API

    Operators can connect to Switchboard to view the state of the nodes. For more information about monitoring proxy health status, see Monitoring Node Health.

Node Health

When determining where to route traffic, the proxy queries an HTTP healthcheck process running on the node. This healthcheck can return as either healthy or unhealthy, or the node can be unresponsive.

Healthy

If the healthcheck process returns HTTP status code 200, the proxy includes the node in its pool of healthy nodes.

When a new or resurrected nodes rejoin the cluster, the proxy continues to route all connections to the currently active node. In the case of failover, the proxy considers all healthy nodes as candidates for new connections.

Switchboard all healthy

Unhealthy

If the healthcheck returns HTTP status code 503, the proxy considers the node unhealthy.

This happens when a node becomes non-primary. For more information, see Cluster Scaling Behavior.

The proxy severs existing connections to newly unhealthy node. The proxy routes new connections to a healthy node, assuming such a node exists. Clients are expected to handle reconnecting on connection failure should the entire cluster become inaccessible.

Switchboard unhealthy

Unresponsive

If node health cannot be determined due to an unreachable or unresponsive healthcheck endpoint, the proxy considers the node unhealthy. This may happen if there is a network partition or if the VM running the node and healthcheck died.

Create a pull request or raise an issue on the source for this page in GitHub