Kako skalirate MySQL, ko promet zraste 100-kratno?

Question

IT Interview Practice · Accepted Answer

Skalirajte v stopnjah: **read replike + predpomnjenje za branja najprej, nato sharding (Vitess) za zapise** — in dodajte združevanje povezav (connection pooling) pred vsem drugim, saj je najcenejši 10x. Branja in zapisi skalirajo drugače, zato ne posegajte po shardingu že prvi dan.

```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: združevanje povezav (connection pooling)

Vsaka MySQL povezava stane pomnilnik in nit. Pri 100x prometa boste izčrpali `max_connections` davno pred CPU. Pooler, kot je **ProxySQL** ali **PgBouncer**, multipleksira tisoče aplikacijskih povezav na nekaj sto DB povezav. To je sprememba konfiguracije, ne prearhitekturiranje — naredite to najprej.

## Korak 1: predpomni branja

Večina delovnih obremenitev je bralno-težkih (pogosto 90%+). Postavite **Redis** spredaj za vroče vrstice — uporabniške profile, strani izdelkov. Zadetek predpomnilnika (cache hit) nikoli ne dotakne MySQL. Uporabite cache-aside: preberi cache → miss → preberi DB → napolni cache. Že samo to lahko absorbira večino 100x.

## Korak 2: read replike

Dodajte **async read replike** in usmerite SELECT-e nanje, zapise na primarno. To skalira branja horizontalno: N replik ≈ N× bralne zmogljivosti. Zanka je **zamik replikacije (replication lag)** — replika je lahko milisekunde-do-sekunde zadaj, zato read-your-own-writes zahteva previdnost (usmerite branja tega uporabnika na primarno ali berite iz predpomnilnika).

## Korak 3: shardaj zapise

Replike ne pomagajo pri zapisih — vsak zapis še vedno zadene eno primarno. Ko throughput zapisov nasiti eno škatlo, **shardaj**. **Vitess** (zgrajen v YouTube) sedi pred MySQL in izvaja sharding, usmerjanje poizvedb in spletno reshardanje brez prepisovanja aplikacije. Shardajte po `user_id`, tako da večina poizvedb ostane enošardnih.

## Pogled s stališča razgovora

Izpraševalci pazijo na **vrstni red**: kandidati, ki takoj shardajo, razkrijejo, da ne vedo, da replike/predpomnjenje rešijo skaliranje branj precej ceneje. Dobro: "dodaj replike in cache." Odlično: ločite pot branja od poti zapisa, poimenujete zamik replikacije kot ceno replik in uvedete sharding šele, ko so *zapisi* — ne branja — ozko grlo.

**Pogosta past:** "kar dodaj read replike", ko je dejansko ozko grlo throughput zapisov. Replike to *poslabšajo* (več replikacijske obremenitve na primarni).

## Kompromisi in načini odpovedi

- **Zamik replikacije:** zastarela branja; prilepite kritična branja na primarno ali uporabite polsinhrono (semi-sync) replikacijo.
- **Naval na predpomnilnik (cache stampede):** mnogo zgrešitev zadene DB naenkrat ob poteku — uporabite locke ali zamaknjene (staggered) TTL-je.
- **Kompleksnost shardinga:** izgubi medshardne joine in transakcije; to plačajte šele, ko vas zapisi prisilijo.
- **Failover:** smrt primarne potrebuje avtomatizirano povzdignitev (Orchestrator); zastarela povzdignjena replika lahko izgubi nedavne zapise.

Korak 0: združevanje povezav (connection pooling)

Korak 1: predpomni branja

Korak 2: read replike

Korak 3: shardaj zapise

Pogled s stališča razgovora

Kompromisi in načini odpovedi

Povezana vprašanja