MySQL High Availability¶

A standalone MySQL server is a single point of failure: one disk, one kernel panic or one unplanned maintenance window takes the whole application down. High availability (HA) means keeping more than one copy of the database ready to take over, with automatic promotion and no manual intervention in the middle of the night.

This page covers HA inside the same datacenter — the most common topology, and the one that solves most real failures (hardware, host, rack, maintenance). For distribution across regions and lower latency between countries, see Multi-Region MySQL.

InteSys deploys this architecture in both forms: on Kubernetes, with an operator handling the database lifecycle, or on virtual machines, with classic replication and a cluster manager. Both run in br-sp-1 (Cirion SAO1) and br-sp-2 (Equinix SP3).

What HA solves — and what it does not¶

The two numbers that define the design:

• RPO (Recovery Point Objective) — how much data you can afford to lose. Asynchronous replication: seconds. Semi-synchronous: practically zero.
• RTO (Recovery Time Objective) — how long until you are back. Automated failover: tens of seconds. Manual: however long it takes someone to wake up.

Topology on Kubernetes¶

For customers already running their applications on Kubernetes, MySQL lives in the cluster itself, managed by a MySQL operator that treats provisioning, replication, failover and backup as declarative state.

The operator reconciles the desired topology; the application uses a single service, and backups leave the cluster for object storage.

• Declarative topology — replica count, MySQL version and backup policy in a manifest, versioned in Git alongside the application.
• StatefulSet with persistent volumes — each instance gets its own volume, with encrypted volume snapshots and a defined retention policy.
• Mandatory anti-affinity — one database pod per physical node. Three replicas on the same hypervisor are not high availability.
• Single endpoint with read/write split — writes go to the primary, reads are spread across the replicas.
• Operator-driven failover — detection, promotion and reconfiguration of the remaining nodes with no intervention.
• Backup and PITR outside the cluster, in object storage.

Topology on virtual machines¶

When the application is not containerized — or when the database must stay outside the cluster as a risk decision — the same guarantee is delivered with dedicated VMs.

A pair of ProxySQL instances answers on a VIP and hides the topology from the application; the cluster manager watches node health and drives promotion.

• Three database nodes — one primary and two replicas, on distinct physical hosts.
• GTID-based replication — replicas reposition themselves automatically after a primary switch, with no manual binlog coordinate arithmetic.
• Proxy layer in a pair — ProxySQL with VIP/keepalived, so the application never needs to know which node is the primary.
• Cluster manager — health checks, decision quorum, promotion and fencing of the old node.
• Backup and binlog outside the database nodes.

Kubernetes or virtual machines?¶

There is no single answer: InteSys operates both topologies, and the choice usually follows where the application already lives.

How failover works¶

1. Detection — loss of contact with the primary confirmed by more than one observer, so a momentary network glitch does not trigger a failover.
2. Fencing — the old primary is isolated before any promotion. Without it, two nodes accept writes and split-brain corrupts the data.
3. Promotion — the most advanced replica takes over, after a replication lag check.
4. Redirection — the proxy starts pointing to the new primary; the application keeps using the same address.
5. Rebuild — the old node rejoins the cluster as a replica, automatically or after inspection, according to the agreed policy.

Replication modes¶

The usual combination: one semi-synchronous replica to guarantee the data and one asynchronous replica to serve reads and backups without affecting write response time.

Monitoring that comes with the cluster¶

High availability without observability is a bet. Every cluster we deliver includes:

• replication lag per replica, alerting before the lag becomes a problem;
• cluster manager state and promotion history;
• connection saturation and proxy queueing;
• error rate and commit latency;
• backup and test-restore success — a backup that was never restored is a hypothesis, not a guarantee.

Data sovereignty¶

Every byte in this cluster stays in Brazil. Both InteSys regions are Brazilian — br-sp-1 (Cirion SAO1), in Cotia/SP, and br-sp-2 (Equinix SP3), in the São Paulo metro area — and data only leaves the country if the customer asks for it.

• Data residency in Brazil — primary nodes, replicas, transaction log archives and backups all live in Brazilian datacenters, on infrastructure operated by InteSys.
• LGPD with no international transfer — in the default configuration there is no cross-border transfer of personal data to document, and no additional legal basis to build.
• Single jurisdiction — Brazilian infrastructure, Brazilian contract and a Brazilian operations team, without the exposure to foreign data-access legislation that reaches providers headquartered abroad.
• Latency as a side effect — keeping data close to Brazilian users is a compliance requirement and a performance gain at the same time.
• Sending data abroad is an explicit customer decision — any copy outside the country exists only when requested, and only on an encrypted volume.

Encrypted volume snapshots¶

On top of the full backup plus binlog for point-in-time recovery, a cluster on Kubernetes can use volume snapshots (CSI VolumeSnapshot): a copy of the entire volume, taken in seconds, without scanning the database.

• Consistent snapshots — the operator coordinates the flush and freezes writes before triggering the snapshot, so a restore does not depend on crash recovery.
• Always on an encrypted volume — data is encrypted at rest and the snapshot inherits that encryption; the key is managed by InteSys or supplied by the customer.
• Encrypted in transit — replicating the snapshot to another destination travels encrypted and is stored encrypted at the destination.
• Retention and tested restores — a defined retention policy and restores exercised periodically; a snapshot that has never been restored is a hypothesis, not a backup.
• Fast recovery — a snapshot brings the whole volume back in minutes; the full backup plus binlog is still what rewinds the data to the instant before the DROP TABLE.

How InteSys deploys it¶

1. Sizing — data volume, write profile, RPO/RTO requirements and maintenance window.
2. Topology — Kubernetes or VMs, replica count and replication mode.
3. Provisioning — nodes spread across distinct physical hosts, with anti-affinity and dedicated storage.
4. Access layer — ProxySQL or a service with read/write split, a single endpoint for the application.
5. Backup and PITR — full backup plus binlog in object storage, outside the database nodes.
6. Failure testing — we take the primary down in a controlled environment and measure real RTO before going to production.
7. Observability and alerting — metrics, dashboards and alerts wired to the operations team.
8. Runbook — a documented procedure for the cases where automation needs a human decision.

Next Steps¶

• PostgreSQL High Availability — The same architecture applied to PostgreSQL
• ClickHouse High Availability — Replicas and shards for analytical workloads
• Multi-Region MySQL — Latency, read replicas and geographic distribution
• Kubernetes — Managed clusters where the database can be operated
• InteSys Datacenters — Details of the br-sp-1 and br-sp-2 regions