Πώς κάνετε scale τη MySQL όταν το traffic αυξηθεί 100x;

Question

IT Interview Practice · Accepted Answer

Κάντε scale σε στάδια: **read replicas + caching για τα reads πρώτα, μετά sharding (Vitess) για τα writes** — και προσθέστε connection pooling πριν από οτιδήποτε άλλο, γιατί είναι το φθηνότερο 10x. Τα reads και τα writes κάνουν scale διαφορετικά, οπότε μην καταφεύγετε στο sharding από την πρώτη μέρα.

```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: connection pooling

Κάθε MySQL connection κοστίζει μνήμη και ένα thread. Στο 100x traffic θα εξαντλήσετε το `max_connections` πολύ πριν τη CPU. Ένας pooler όπως το **ProxySQL** ή το **PgBouncer** κάνει multiplex χιλιάδες app connections πάνω σε λίγες εκατοντάδες DB connections. Είναι αλλαγή config, όχι rearchitecture — κάντε το πρώτο.

## Βήμα 1: cache τα reads

Τα περισσότερα workloads είναι read-heavy (συχνά 90%+). Βάλτε το **Redis** μπροστά για hot rows — user profiles, product pages. Ένα cache hit δεν αγγίζει ποτέ τη MySQL. Χρησιμοποιήστε cache-aside: read cache → miss → read DB → populate cache. Αυτό και μόνο μπορεί να απορροφήσει την πλειοψηφία του 100x.

## Βήμα 2: read replicas

Προσθέστε **async read replicas** και δρομολογήστε τα SELECTs σε αυτά, τα writes στο primary. Αυτό κάνει scale τα reads οριζόντια: N replicas ≈ N× read capacity. Το πιάσιμο είναι το **replication lag** — ένα replica μπορεί να είναι milliseconds-έως-δευτερόλεπτα πίσω, οπότε το read-your-own-writes χρειάζεται προσοχή (δρομολογήστε τα reads αυτού του χρήστη στο primary, ή διαβάστε από cache).

## Βήμα 3: shard τα writes

Τα replicas δεν βοηθάνε τα writes — κάθε write χτυπάει ακόμα το μοναδικό primary. Όταν το write throughput κορεσίσει ένα box, κάντε **shard**. Το **Vitess** (χτισμένο στο YouTube) κάθεται μπροστά από τη MySQL και κάνει sharding, query routing, και online resharding χωρίς ξαναγράψιμο της app. Κάντε shard με `user_id` ώστε τα περισσότερα queries να μένουν single-shard.

## Οπτική συνέντευξης

Οι συνεντευκτές προσέχουν τη **σειρά**: υποψήφιοι που κάνουν αμέσως shard αποκαλύπτουν ότι δεν ξέρουν ότι τα replicas/caching λύνουν το read scaling πολύ φθηνότερα. Καλό: "πρόσθεσε replicas και cache." Εξαιρετικό: διαχωρίζετε το read path από το write path, κατονομάζετε το replication lag ως το κόστος των replicas, και εισάγετε sharding μόνο όταν τα *writes* — όχι τα reads — είναι το bottleneck.

**Συνηθισμένη παγίδα:** "απλά πρόσθεσε read replicas" όταν το πραγματικό bottleneck είναι το write throughput. Τα replicas το κάνουν *χειρότερο* (περισσότερο replication load στο primary).

## Trade-offs & τρόποι αποτυχίας

- **Replication lag:** stale reads· καρφώστε τα κρίσιμα reads στο primary ή χρησιμοποιήστε semi-sync replication.
- **Cache stampede:** πολλά misses χτυπάνε τη βάση ταυτόχρονα στη λήξη — χρησιμοποιήστε locks ή staggered TTLs.
- **Πολυπλοκότητα sharding:** χάνει cross-shard joins και transactions· πληρώστε το μόνο όταν τα writes το επιβάλλουν.
- **Failover:** ο θάνατος του primary χρειάζεται αυτοματοποιημένη προαγωγή (Orchestrator)· ένα stale promoted replica μπορεί να χάσει πρόσφατα writes.

Βήμα 0: connection pooling

Βήμα 1: cache τα reads

Βήμα 2: read replicas

Βήμα 3: shard τα writes

Οπτική συνέντευξης

Trade-offs & τρόποι αποτυχίας

Σχετικές ερωτήσεις