Skip to content

Databases Updated 2026-05-29

MySQL / MariaDB / Percona high availability

High-availability topologies for MySQL, MariaDB, and Percona on Stack Harbor PaaS — auto-clustering, primary-secondary, multi-primary, Galera, and multi-region clusters.

Stack Harbor PaaS provisions MySQL, MariaDB, and Percona clusters from the topology wizard. This page covers the available HA topologies, when to pick each, and what the platform takes care of versus what you configure.

What auto-clustering does

When you enable Auto-Clustering at create time, the platform:

  • Provisions the chosen number of database nodes.
  • Configures replication between them according to the selected scheme.
  • Stands up a ProxySQL tier in front of the cluster, with the SQL routing rules wired up.
  • Issues a single application-facing endpoint — proxy.{environment_name}.{domain} — that survives node failovers.
  • Wires up the auto-recovery hooks (more on that below).

Applications target the ProxySQL endpoint, not individual nodes, so a node failover does not require an application restart.

Available topologies

Auto-clustering

Pick the scheme in the topology wizard. The available schemes are:

  • Primary-Secondary
  • Primary-Primary
  • Galera (MariaDB only)

The same dialog also sets the number of nodes, the cloudlet limit per node, and ProxySQL sizing.

Primary-Secondary replication

Async replication. One writer (primary), one or more readers (secondaries). The primary streams a binary log; secondaries read and apply. Best for read-heavy workloads where the cluster needs to serve more read traffic than a single node can handle.

See Database primary-secondary replication for the manual setup procedure.

Multi-Primary replication

Async bidirectional replication between two primaries. Both nodes accept writes; conflicts are resolved by configured rules. Best for HA writes — if one primary fails, the other takes over, and there’s no promotion step.

A note on conflict resolution: multi-primary is not a substitute for a single-writer topology when your workload includes concurrent writes to the same row from different primaries. Galera is the better fit there.

Galera cluster

Synchronous multi-primary replication on MariaDB. All nodes accept writes; transactions are committed only when a write-set quorum is reached. Best for HA writes with strong consistency.

Galera has some operational quirks — split-brain recovery, joiner-state handling, the “wsrep_provider” tuning — that are documented in the upstream Galera reference. The platform’s auto-clustering setup ships sane defaults.

Multi-region cluster

A clustered topology spread across two or more environment regions. Each region holds part of the cluster; replication is asynchronous between regions. Best for disaster-recovery topologies where you need to survive the loss of a whole region.

A note on latency: write performance in a multi-region cluster is bounded by inter-region latency. For workloads sensitive to write latency, prefer a single-region HA topology and run a separate replica in another region for DR.

Cluster Recovery add-on

The Cluster Recovery add-on watches the cluster’s health and restarts members that fall out. It handles common transient failures — a brief network hiccup, an OOM event on one node — automatically, without operator intervention.

Install it from the marketplace against any clustered MySQL-family environment. The add-on is opt-in; we recommend installing it on every clustered production environment.

Galera cluster recovery

When a Galera cluster suffers a full outage — all nodes down at the same time — the cluster needs to be bootstrapped from the node with the highest seqno. The procedure:

  1. Identify the node with the highest seqno (look at grastate.dat on each node).
  2. Bootstrap that node first using galera_new_cluster (or the equivalent script for your version).
  3. Start the remaining nodes — they will join as state-transfer recipients.

The Cluster Recovery add-on automates this for partial failures. Full-cluster outages still need operator review, because the wrong bootstrap node will lose committed transactions.

See also