Miten skaalaat MySQL:n, kun liikenne kasvaa 100-kertaiseksi?

Question

IT Interview Practice · Accepted Answer

Skaalaa vaiheittain: **read replicat + caching lukemisille ensin, sitten sharding (Vitess) kirjoituksille** — ja lisää connection pooling ennen mitään muuta, koska se on halvin 10-kertaistus. Lukemiset ja kirjoitukset skaalautuvat eri tavalla, joten älä tartu shardaukseen ensimmäisenä päivänä.

```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
```

## Vaihe 0: connection pooling

Jokainen MySQL-yhteys maksaa muistia ja säikeen. 100-kertaisella liikenteellä loppuu `max_connections` kauan ennen CPU:ta. Pooler kuten **ProxySQL** tai **PgBouncer** multipleksoi tuhannet sovellusyhteydet muutamaan sataan DB-yhteyteen. Se on konfiguraatiomuutos, ei uudelleenarkkitehtuuri — tee se ensin.

## Vaihe 1: cachea lukemiset

Useimmat kuormat ovat luku-painotteisia (usein 90 %+). Laita **Redis** eteen kuumille riveille — käyttäjäprofiilit, tuotesivut. Cache hit ei koskaan kosketa MySQL:ää. Käytä cache-asidea: lue cache → miss → lue DB → täytä cache. Tämä yksin voi imeä valtaosan 100-kertaistuksesta.

## Vaihe 2: read replicat

Lisää **async read replicat** ja reititä SELECTit niihin, kirjoitukset primaryyn. Tämä skaalaa lukemisia horisontaalisesti: N replikaa ≈ N× lukukapasiteetti. Koukku on **replication lag** — replika voi olla millisekunteja-sekunteja jäljessä, joten read-your-own-writes vaatii huolellisuutta (reititä kyseisen käyttäjän lukemiset primaryyn, tai lue cachesta).

## Vaihe 3: shardaa kirjoitukset

Replikat eivät auta kirjoituksia — jokainen kirjoitus osuu edelleen yhteen primaryyn. Kun kirjoitus-throughput saturoi yhden koneen, **shardaa**. **Vitess** (rakennettu YouTubessa) istuu MySQL:n edessä ja tekee shardauksen, kyselyn reitityksen ja online-uudelleenshardauksen sovellusta uudelleenkirjoittamatta. Shardaa `user_id`:llä, jotta useimmat kyselyt pysyvät yhden shardin sisällä.

## Haastattelunäkökulma

Haastattelijat tarkkailevat **järjestystä**: kandidaatit, jotka shardaavat heti, paljastavat, etteivät tiedä replikojen/cachingin ratkaisevan lukuskaalauksen paljon halvemmalla. Hyvä: "lisää replikat ja cache." Loistava: erotat lukupolun kirjoituspolusta, nimeät replication lagin replikojen kustannuksena ja tuot shardauksen mukaan vain kun *kirjoitukset* — eivät lukemiset — ovat pullonkaula.

**Yleinen ansa:** "lisää vain read replikoita", kun todellinen pullonkaula on kirjoitus-throughput. Replikat tekevät siitä *pahemman* (enemmän replication-kuormaa primaryyn).

## Kompromissit ja virhetilanteet

- **Replication lag:** vanhentuneet lukemiset; kiinnitä kriittiset lukemiset primaryyn tai käytä semi-sync-replikointia.
- **Cache stampede:** monta missiä osuu DB:hen kerralla vanhenemishetkellä — käytä lukkoja tai porrastettuja TTL:iä.
- **Shardauksen monimutkaisuus:** menettää cross-shard-liitokset ja transaktiot; maksa tämä vasta kun kirjoitukset pakottavat.
- **Failover:** primaryn kuolema tarvitsee automatisoidun ylennyksen (Orchestrator); vanhentunut ylennetty replika voi menettää tuoreita kirjoituksia.

Vaihe 0: connection pooling

Vaihe 1: cachea lukemiset

Vaihe 2: read replicat

Vaihe 3: shardaa kirjoitukset

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset