Jak skalować MySQL, gdy ruch rośnie 100x?

Question

IT Interview Practice · Accepted Answer

Skaluj etapami: **najpierw read repliki + cache dla odczytów, potem sharding (Vitess) dla zapisów** — i dodaj connection pooling przed czymkolwiek innym, bo to najtańsze 10x. Odczyty i zapisy skalują się różnie, więc nie sięgaj po sharding pierwszego dnia.

```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żde połączenie MySQL kosztuje pamięć i wątek. Przy 100x ruchu wyczerpiesz `max_connections` długo przed CPU. Pooler jak **ProxySQL** lub **PgBouncer** multipleksuje tysiące połączeń aplikacji na kilkaset połączeń DB. To zmiana konfiguracji, nie przebudowa architektury — zrób to najpierw.

## Krok 1: cache'uj odczyty

Większość obciążeń jest read-heavy (często 90%+). Postaw **Redis** z przodu dla gorących wierszy — profile użytkowników, strony produktów. Cache hit nigdy nie dotyka MySQL. Użyj cache-aside: odczyt cache → miss → odczyt DB → wypełnij cache. Samo to może zaabsorbować większość ze 100x.

## Krok 2: read repliki

Dodaj **asynchroniczne read repliki** i kieruj SELECT-y na nie, zapisy na primary. To skaluje odczyty poziomo: N replik ≈ N× pojemności odczytu. Haczykiem jest **replication lag** — replika może być milisekundy-do-sekund w tyle, więc read-your-own-writes wymaga ostrożności (kieruj odczyty tego użytkownika na primary lub czytaj z cache).

## Krok 3: sharduj zapisy

Repliki nie pomagają zapisom — każdy zapis wciąż trafia w jeden primary. Gdy throughput zapisów wysyci jedną maszynę, **sharduj**. **Vitess** (zbudowany w YouTube) staje przed MySQL i wykonuje sharding, routing zapytań i online resharding bez przepisywania aplikacji. Sharduj po `user_id`, aby większość zapytań pozostała single-shard.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówcy obserwują **kolejność**: kandydaci, którzy od razu shardują, zdradzają, że nie wiedzą, iż repliki/cache rozwiązują skalowanie odczytów znacznie taniej. Dobrze: „dodaj repliki i cache". Świetnie: separujesz ścieżkę odczytu od ścieżki zapisu, nazywasz replication lag jako koszt replik i wprowadzasz sharding dopiero, gdy wąskim gardłem są *zapisy* — nie odczyty.

**Częsta pułapka:** „po prostu dodaj read repliki", gdy faktycznym wąskim gardłem jest throughput zapisów. Repliki pogarszają to (więcej obciążenia replikacją na primary).

## Kompromisy i tryby awarii

- **Replication lag:** nieświeże odczyty; przypnij krytyczne odczyty do primary lub użyj semi-sync replication.
- **Cache stampede:** wiele missów uderza w DB naraz przy wygaśnięciu — użyj blokad lub rozłożonych TTL-i.
- **Złożoność shardingu:** traci joiny i transakcje międzyshardowe; płać za to dopiero, gdy zapisy tego wymuszą.
- **Failover:** śmierć primary wymaga zautomatyzowanej promocji (Orchestrator); nieświeża promowana replika może utracić ostatnie zapisy.

Krok 0: connection pooling

Krok 1: cache'uj odczyty

Krok 2: read repliki

Krok 3: sharduj zapisy

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i tryby awarii

Powiązane pytania