Kako skalirati MySQL kada promet naraste 100 puta?

Question

IT Interview Practice · Accepted Answer

Skalirajte u fazama: **read replike + cachiranje za čitanja prvo, zatim sharding (Vitess) za upise** — i dodajte connection pooling prije svega ostalog, jer je to najjeftinijih 10x. Čitanja i upisi skaliraju se drukčije, pa ne posežite za shardingom prvog dana.

```text
        ┌─▶ Cache (Redis) ── hit ──▶ return
App ─▶ Pool(PgBouncer/ProxySQL)      miss ▼
        │                    ┌─▶ Read replica 1 ┐
        ├──── reads ─────────┼─▶ Read replica 2 ┼─ (async replication)
        │                    └─▶ Read replica N ┘
        └──── writes ──▶ Primary ──▶ (later) Vitess shards ─▶ Primary A / Primary B
```

## Korak 0: connection pooling

Svaka MySQL veza košta memoriju i nit. Pri 100x prometu iscrpit ćete `max_connections` puno prije CPU-a. Pooler poput **ProxySQL-a** ili **PgBouncera** multipleksira tisuće aplikacijskih veza na nekoliko stotina DB veza. To je promjena konfiguracije, ne rearhitektura — napravite to prvo.

## Korak 1: cachirajte čitanja

Većina radnih opterećenja je read-heavy (često 90%+). Stavite **Redis** sprijeda za vruće retke — korisnički profili, stranice proizvoda. Cache hit nikada ne dotakne MySQL. Koristite cache-aside: čitaj cache → miss → čitaj DB → popuni cache. Samo ovo može apsorbirati većinu 100x.

## Korak 2: read replike

Dodajte **async read replike** i usmjerite SELECT-ove na njih, upise na primary. To horizontalno skalira čitanja: N replika ≈ N× kapacitet čitanja. Kvaka je **replication lag** — replika može zaostajati milisekunde do sekunde, pa read-your-own-writes treba oprez (usmjerite čitanja tog korisnika na primary, ili čitajte iz cachea).

## Korak 3: shardirajte upise

Replike ne pomažu upisima — svaki upis i dalje pogađa jedini primary. Kada write throughput zasiti jedan uređaj, **shardirajte**. **Vitess** (izgrađen na YouTubeu) stoji ispred MySQL-a i radi sharding, usmjeravanje upita i online resharding bez prepisivanja aplikacije. Shardirajte po `user_id` kako bi većina upita ostala single-shard.

## Perspektiva intervjua

Ispitivači paze na **redoslijed**: kandidati koji odmah shardiraju otkrivaju da ne znaju da replike/cachiranje rješavaju skaliranje čitanja daleko jeftinije. Dobro: "dodaj replike i cache." Odlično: razdvajate put čitanja od puta upisa, imenujete replication lag kao trošak replika i uvodite sharding tek kad su *upisi* — a ne čitanja — usko grlo.

**Uobičajena zamka:** "samo dodaj read replike" kad je stvarno usko grlo write throughput. Replike to čine *gorim* (više replikacijskog opterećenja na primaryju).

## Kompromisi i načini otkazivanja

- **Replication lag:** zastarjela čitanja; prikvačite kritična čitanja na primary ili koristite semi-sync replikaciju.
- **Cache stampede:** mnogo misseva pogodi DB odjednom pri isteku — koristite lockove ili raspoređene TTL-ove.
- **Složenost shardinga:** gubi cross-shard joinove i transakcije; platите to tek kad vas upisi prisile.
- **Failover:** smrt primaryja treba automatiziranu promociju (Orchestrator); zastarjela promovirana replika može izgubiti nedavne upise.

Korak 0: connection pooling

Korak 1: cachirajte čitanja

Korak 2: read replike

Korak 3: shardirajte upise

Perspektiva intervjua

Kompromisi i načini otkazivanja

Povezana pitanja