Jak škálujete MySQL, když provoz vzroste 100×?

Question

IT Interview Practice · Accepted Answer

Škálujte po fázích: **nejprve read repliky + caching pro čtení, pak sharding (Vitess) pro zápisy** — a před vším ostatním přidejte connection pooling, protože je to nejlevnějších 10×. Čtení a zápisy škálují jinak, takže nesahejte po shardingu první den.

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

## Krok 0: connection pooling

Každé MySQL spojení stojí paměť a vlákno. Při 100× provozu vyčerpáte `max_connections` dávno před CPU. Pooler jako **ProxySQL** nebo **PgBouncer** multiplexuje tisíce aplikačních spojení na pár set DB spojení. Je to změna konfigurace, ne přearchitektování — udělejte to první.

## Krok 1: nacachuj čtení

Většina workloadů je read-heavy (často 90 %+). Před hot řádky postavte **Redis** — uživatelské profily, produktové stránky. Cache hit se MySQL vůbec nedotkne. Použijte cache-aside: přečti cache → miss → přečti DB → naplň cache. Tohle samo dokáže pohltit většinu z oněch 100×.

## Krok 2: read repliky

Přidejte **async read repliky** a směrujte SELECTy na ně, zápisy na primary. To škáluje čtení horizontálně: N replik ≈ N× kapacity čtení. Háček je **replication lag** — replika může být milisekundy až sekundy pozadu, takže read-your-own-writes vyžaduje pozornost (směrujte čtení tohoto uživatele na primary, nebo čtěte z cache).

## Krok 3: shardujte zápisy

Repliky zápisům nepomohou — každý zápis stále zasáhne jeden primary. Když throughput zápisů nasytí jeden stroj, **shardujte**. **Vitess** (postavený v YouTube) sedí před MySQL a dělá sharding, směrování dotazů a online resharding bez přepisu aplikace. Shardujte podle `user_id`, aby většina dotazů zůstala single-shard.

## Pohled z pohovoru

Tazatelé sledují **pořadí**: kandidáti, kteří okamžitě shardují, prozrazují, že nevědí, že repliky/caching řeší škálování čtení mnohem levněji. Dobré: „přidejte repliky a cache.“ Skvělé: oddělíte read path od write path, pojmenujete replication lag jako cenu replik a sharding zavedete, teprve když jsou úzkým hrdlem *zápisy* — ne čtení.

**Častá past:** „prostě přidej read repliky“, když skutečným úzkým hrdlem je throughput zápisů. Repliky to *zhorší* (víc replikační zátěže na primary).

## Kompromisy a režimy selhání

- **Replication lag:** zastaralá čtení; pinněte kritická čtení na primary nebo použijte semi-sync replikaci.
- **Cache stampede:** mnoho missů zasáhne DB naráz při expiraci — použijte zámky nebo rozprostřené TTL.
- **Složitost shardingu:** ztrácí cross-shard joiny a transakce; plaťte to, až vás k tomu zápisy donutí.
- **Failover:** smrt primary vyžaduje automatizované povýšení (Orchestrator); zastaralá povýšená replika může ztratit nedávné zápisy.

Krok 0: connection pooling

Krok 1: nacachuj čtení

Krok 2: read repliky

Krok 3: shardujte zápisy

Pohled z pohovoru

Kompromisy a režimy selhání

Související otázky