Multi-Region MySQL¶

An application running in one region and reaching a MySQL database in another can degrade badly even when the database server has plenty of CPU, memory and disk headroom. The bottleneck is rarely MySQL — it is the network between the application and the database.

Every SQL operation costs at least one round trip over the WAN. A transaction with five statements pays the link latency five times, and any packet loss adds TCP retransmissions, response-time spikes and, eventually, application timeouts.

InteSys works across every layer of this problem, from transparent optimizations for legacy systems to complete regional architectures with replication, caching and geographic data distribution — operating from two Tier III Brazilian regions: br-sp-1 (Cirion SAO1, Cotia/SP) and br-sp-2 (Equinix SP3, Tamboré/SP).

The problem¶

In a traditional application, a single transaction runs a sequence such as:

BEGIN → SELECT → UPDATE → INSERT → COMMIT

With the database in another region, transaction time is dictated by the network: five statements, five RTTs, plus the retransmissions caused by packet loss.

Between br-sp-1 and br-sp-2 latency is a few milliseconds — both regions sit in the São Paulo metropolitan area and interconnect through Lan2Lan links or encrypted tunnels. A Brazil ↔ United States link is an entirely different order of magnitude, above a hundred milliseconds of RTT. That gap is what decides which queries may cross the WAN and which must be answered locally.

The goals of a regional architecture are to:

• reduce the number of SQL round trips crossing the WAN;
• move reads and high-frequency data close to the application;
• keep writes consistent and controlled;
• increase tolerance to network instability;
• preserve compatibility with legacy applications wherever possible;
• allow gradual evolution without rewriting the system.

Architecture catalog¶

1. Resilient inter-region connectivity¶

Before touching the database, we stabilize transport: redundant paths, VPNs, alternate routing and continuous observability of RTT, jitter and packet loss.

Best for: environments with packet loss, unstable routes or a single WAN path. Benefit: stability and predictability. Limitation: it does not remove the physical latency between regions.

2. ProxySQL next to the application¶

ProxySQL is deployed in the same region as the application, between it and the remote MySQL. It centralizes connections, keeps persistent pools and lets us apply routing rules and query caching.

Best for: legacy applications, high connection counts, or the need for a control layer without code changes. Benefits: connection pooling, centralized query control, per-digest observability, a foundation for local replicas, and selective caching. Limitation: non-cached queries still reach the remote region.

3. Read replica in Brazil¶

The primary stays where it is and an asynchronous replica is kept in br-sp-1 or br-sp-2. ProxySQL routes suitable reads to the local replica and keeps writes on the primary.

Best for: read-heavy applications that tolerate eventual consistency on part of their queries. Benefits: low-latency local SELECTs, less WAN usage and a significant drop in average response time — without making the replica writable. Watch out: reads issued immediately after a write may need to go to the primary to stay consistent.

4. Selective query routing¶

Instead of sending every SELECT to the replica, we map which queries tolerate eventual consistency and write specific ProxySQL rules — by digest, table or user.

Catalogs, reports and reference data go to the local replica; balances, checkout, SELECT ... FOR UPDATE and read-after-write stay on the primary.

Benefit: safe, progressive adoption — one query at a time, with no all-or-nothing bet.

5. Regional cache with Valkey/Redis¶

Repetitive data lives in a Valkey or Redis instance in the application's region, sharply reducing the number of queries sent to the remote database. Good candidates: settings, profiles, permissions, catalogs, sessions, expensive query results and derived data.

Best for: data with a high read rate and a well-defined invalidation strategy. Benefit: the most frequent queries are answered locally, regardless of how far away MySQL is.

6. Combined architecture — ProxySQL + replica + cache¶

This is the best balance of gain, risk and complexity for systems already in production, and the InteSys default recommendation.

The application talks to a local endpoint. ProxySQL decides where each query goes; the cache serves high-frequency data; the replica serves selected reads; the primary remains the single write authority.

Best for: critical systems that must evolve without a deep rewrite.

7. Partial replication¶

Not every database needs to be brought to Brazil. We can replicate only the databases or datasets the Brazilian application actually consumes.

Best for: very large databases, cleanly separated domains, or cases where only a fraction of the data needs to be close to the application. Benefits: less replication traffic, lower infrastructure cost and segmentation by functional domain.

8. Regional API / data service layer¶

In new or modernized systems, the application stops issuing dozens of SQL statements over the WAN and calls a regional API instead. That service runs the transaction next to the primary or combines local cache and replica.

Best for: modernization, microservices and transactional flows with many round trips. Benefit: trades several SQL round trips for a single business-level call.

9. Geographic sharding / regional ownership¶

For systems that must write locally in more than one region, data is partitioned by customer, tenant, country or functional domain: Brazilian tenants write in Brazil, US tenants write in the US, and each region replicates what the other needs for reads only.

Best for: global platforms and multi-tenant SaaS. Complexity: high — it demands clear ownership, consistency and routing rules.

High availability across br-sp-1 and br-sp-2¶

Cutting latency solves performance, not availability. When the database is critical, InteSys spreads the solution across both Brazilian regions — independent in power, cooling and operator, and only a few milliseconds apart.

Primary in one region, standby in the other, highly available ProxySQL in both, and controlled promotion on failure.

How it works in practice:

• Primary in br-sp-1, standby in br-sp-2 (or the reverse) — the short distance allows semi-synchronous replication, with a near-zero data-loss window that intercontinental links cannot offer.
• Highly available ProxySQL in both regions, with VIP/keepalived and the same rule set, so the application keeps using a single endpoint.
• Controlled failover: replica promotion gated on replication lag checks, with fencing of the old primary to avoid split-brain.
• Backups and PITR on storage separate from both regions, with periodic restore testing.
• Reads use the standby: the secondary region is not idle — it serves read queries while tracking the primary.

Managed MySQL on Kubernetes¶

For customers already running their applications on Kubernetes, InteSys also operates MySQL inside the cluster, with a MySQL operator handling the database lifecycle.

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

What this approach delivers:

• Declarative topology — replica count, MySQL version and backup policy described as a manifest, versioned in Git alongside the application.
• StatefulSet with persistent storage — each instance has its own volume, with snapshots and a retention policy.
• Operator-driven failover — replica promotion and topology reconfiguration without manual intervention.
• Single endpoint with read/write split — writes go to the primary, reads spread across the replicas, exactly as ProxySQL does outside the cluster.
• Spread across br-sp-1 and br-sp-2 — anti-affinity rules distribute pods across regions, so losing one region does not take down the quorum.
• Backup and PITR outside the cluster, on object storage, because a backup inside the same cluster is not a backup.

Decision matrix¶

By scenario¶

What must not go to the replica¶

Regionalized reads are only safe if consistency-sensitive queries stay on the primary:

Monitoring replication lag is part of the solution, not an add-on: routing rules must react to lag and pull the replica out of rotation when it falls behind.

How InteSys rolls this out¶

1. Assessment — measure RTT, jitter, packet loss, connection volume and transactional behavior.
2. Observability — identify the most frequent, slowest and most WAN-sensitive queries, by digest.
3. ProxySQL — introduce a centralized, measurable access layer.
4. Regionalized reads — add a Brazilian MySQL replica where applicable.
5. Cache — select the right data for Valkey/Redis and define the invalidation strategy.
6. Consistency rules — critical reads on the primary, safe queries in the local region.
7. High availability — remove single points of failure in ProxySQL, cache and database, spread across br-sp-1 and br-sp-2.
8. Architectural evolution — regional API, partial replication, Kubernetes or geographic sharding, as needed.

Each step is measured before moving to the next, so you can stop as soon as the gain meets your goal.

Next Steps¶

• Kubernetes — Managed clusters where MySQL can be operated
• InteSys Datacenters — Details of the br-sp-1 and br-sp-2 regions
• DevOps Overview — Full service catalog