Hogyan skálázod a MySQL-t, amikor a forgalom 100x-osára nő?

Question

IT Interview Practice · Accepted Answer

Skálázz szakaszokban: **először read replikák + caching az olvasásokhoz, majd shardelés (Vitess) az írásokhoz** — és adj hozzá connection poolingot minden más előtt, mert az a legolcsóbb 10x. Az olvasások és írások eltérően skálázódnak, ezért ne nyúlj a shardeléshez az első napon.

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

## 0. lépés: connection pooling

Minden MySQL connection memóriába és egy szálba kerül. 100x forgalomnál kimeríted a `max_connections`-t jóval a CPU előtt. Egy pooler, mint a **ProxySQL** vagy **PgBouncer**, több ezer app connectiont multiplexel néhány száz DB connectionre. Ez egy config változtatás, nem újratervezés — csináld először.

## 1. lépés: cache-eld az olvasásokat

A legtöbb workload olvasás-nehéz (gyakran 90%+). Tegyél **Redist** elöl a forró soroknak — felhasználói profilok, termékoldalak. Egy cache hit soha nem éri el a MySQL-t. Használj cache-aside-ot: olvasd a cache-t → miss → olvasd a DB-t → töltsd fel a cache-t. Ez önmagában felszívhatja a 100x többségét.

## 2. lépés: read replikák

Adj hozzá **async read replikákat** és irányítsd a SELECT-eket rájuk, az írásokat a primaryre. Ez horizontálisan skálázza az olvasásokat: N replika ≈ N× olvasási kapacitás. A bökkenő a **replikációs lag** — egy replika milliszekundumokkal-másodpercekkel lehet lemaradva, így a read-your-own-writes odafigyelést igényel (irányítsd az adott felhasználó olvasásait a primaryre, vagy olvass cache-ből).

## 3. lépés: shardeld az írásokat

A replikák nem segítenek az írásokon — minden írás továbbra is az egyetlen primaryt éri. Amikor az írási throughput telíti az egy gépet, **shardelj**. A **Vitess** (a YouTube-nál épült) a MySQL elé kerül és shardelést, lekérdezés-irányítást és online reshardolást végez az app átírása nélkül. Shardelj `user_id` szerint, hogy a legtöbb lekérdezés single-shard maradjon.

## Interjú szemszög

Az interjúztatók a **sorrendet** figyelik: azok a jelöltek, akik azonnal shardelnek, elárulják, hogy nem tudják, a replikák/caching sokkal olcsóbban oldják meg az olvasás-skálázást. Jó: "adj hozzá replikákat és egy cache-t." Kiváló: szétválasztod az olvasási utat az írási úttól, megnevezed a replikációs lagot a replikák költségeként, és csak akkor vezetsz be shardelést, amikor az *írások* — nem az olvasások — a szűk keresztmetszet.

**Gyakori csapda:** "csak adj hozzá read replikákat", amikor a valódi szűk keresztmetszet az írási throughput. A replikák ezt *rosszabbá* teszik (több replikációs terhelés a primaryn).

## Kompromisszumok és hibamódok

- **Replikációs lag:** állott olvasások; rögzítsd a kritikus olvasásokat a primaryre vagy használj semi-sync replikációt.
- **Cache stampede:** sok miss éri az adatbázist egyszerre lejáratkor — használj lockokat vagy eltolt TTL-eket.
- **Shardelési komplexitás:** elveszti a cross-shard joinokat és tranzakciókat; csak akkor fizesd meg ezt, amikor az írások kikényszerítik.
- **Failover:** a primary halála automatizált előléptetést igényel (Orchestrator); egy állott előléptetett replika elveszíthet friss írásokat.

0. lépés: connection pooling

1. lépés: cache-eld az olvasásokat

2. lépés: read replikák

3. lépés: shardeld az írásokat

Interjú szemszög

Kompromisszumok és hibamódok

Kapcsolódó kérdések