High availability

As a feature, High Availability (HA) preserves the uptime of your database cluster by executing a failover from a failed host to a healthy replacement. When HA is enabled for a cluster, the Crunchy Bridge control plane creates a hidden hot standby which receives the same writes as your primary database cluster. If something goes wrong with your primary host, the control plane will promote the standby to replace the impacted cluster in an instant. Once the promotion occurs, the original cluster is destroyed and a new standby host is created.

For services that are sensitive to protracted downtime we recommend using our HA feature. Without HA, your instance will be backed up and monitored by our control plane. In the event of a loss of service, the control plane will automatically restore your instance using the most recent backup and of all WAL (Write-Ahead Logging) segments that have been generated since the latest backup. For small, inactive clusters this could be a matter of minutes, but for larger or active clusters this may take many hours.

Hint

It is important that your services employ reconnection logic within your database library because during a failover all existing connections will be dropped. Many ORMs and drivers support this out of the box. During a failover, your connection string does not change.

HA is configurable for both primary and read replica clusters at provisioning-time or later via cluster resize. HA standby instances are always the same size as the instance they back up.