Migration μιας βάσης 10TB με μηδενικό downtime: ποιο είναι το σχέδιο;

Question

IT Interview Practice · Accepted Answer

**Κάντε dual-write σε παλιά και νέα, backfill την ιστορία στο παρασκήνιο, χρησιμοποιήστε CDC για να προλάβετε την ουρά, verify με shadow reads, μετά γυρίστε τα reads ατομικά — με ένα rollback path σε κάθε βήμα.** Ποτέ δεν κατεβάζετε την app· τρέχετε και τις δύο βάσεις παράλληλα μέχρι η νέα να είναι αποδεδειγμένα πανομοιότυπη, μετά κάνετε cutover.

## Αρχιτεκτονική

```text
        ┌── write ──▶ OLD DB (source of truth) ──CDC (Debezium)──┐
 App ───┤                                                        ▼
        └── write ──▶ NEW DB ◀──── backfill job (historical rows)
                        │
   shadow reads (compare OLD vs NEW) ─▶ diff metrics ─▶ atomic cutover ─▶ NEW is truth
                                                          (flip flag; rollback = flip back)
```

## Πώς λειτουργεί

1. **Dual-write.** Η app γράφει κάθε αλλαγή και στην OLD και στη NEW. Οι νέες rows μένουν σε sync από τώρα· λείπει μόνο η ιστορία.
2. **Backfill.** Ένα background job αντιγράφει historical rows σε batches (throttled για προστασία της prod). Χρησιμοποιήστε `INSERT ... ON CONFLICT DO NOTHING` ώστε να είναι idempotent και ασφαλές να ξανατρέξει.
3. **CDC catch-up.** Το dual-write μπορεί να χάσει rows που γράφτηκαν κατά το άναμμα. Το **Debezium** που κάνει stream το WAL/binlog της OLD DB κάνει replay κάθε αλλαγή, κλείνοντας το κενό που δεν μπορεί το backfill.
4. **Shadow reads.** Διαβάστε από τη NEW παράλληλα με την OLD, **συγκρίνετε τα αποτελέσματα**, και εκπέμψτε ένα diff metric. Μηδενικά diffs με τον χρόνο = η NEW είναι αξιόπιστη.
5. **Cutover.** Γυρίστε ένα feature flag ώστε τα reads (μετά τα writes) να πάνε στη NEW. Είναι αλλαγή config, όχι deploy — ακαριαία, και **αναστρέψιμη με γύρισμα πίσω**.

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

Ο συνεντευκτής θέλει **πώς εγγυάστε καμία απώλεια δεδομένων και μηδενικό downtime**, και αν έχετε **rollback**. Καλές απαντήσεις αναφέρουν dual-write· εξαιρετικές απαντήσεις προσθέτουν **CDC για να πιάσετε το race window**, **shadow reads για verify πριν εμπιστευτείτε**, και ένα **ατομικό, αναστρέψιμο flag flip**. Η κλασική παγίδα είναι "backfill μετά switch" χωρίς verification — ανακαλύπτετε το mismatch αφού το χτυπήσουν οι χρήστες, χωρίς δρόμο επιστροφής.

## Trade-offs & αποτυχία

- **Dual-write consistency.** Αν το NEW write αποτύχει αλλά το OLD πετύχει, αποκλίνουν. Κάντε την OLD authoritative και αφήστε το CDC να επισκευάσει τη NEW, αντί να αποτυγχάνετε το request του χρήστη.
- **Κόστος & πολυπλοκότητα.** Η λειτουργία δύο βάσεων + CDC + backfill είναι ακριβή και λειτουργικά βαριά — δικαιολογημένη μόνο για μεγάλα, κρίσιμα stores.
- **Schema changes** κατά το migration πολλαπλασιάζουν το ρίσκο· παγώστε το schema μέχρι το cutover.
- **Backfill load.** Ένα un-throttled backfill μπορεί να κορεσίσει το prod I/O και να προκαλέσει διακοπή — το αντίθετο του στόχου· κάντε batch και rate-limit.
- **Rollback window.** Κρατήστε το dual-writing (τώρα NEW→OLD) για μέρες μετά το cutover ώστε να μπορείτε να γυρίσετε πίσω αν αναδυθεί ένα λανθάνον bug. Μόνο τότε αποσύρετε την OLD.
- **Πότε όχι:** μια μικρή βάση με maintenance window δεν χρειάζεται αυτό — ένα 30λεπτο `pg_dump`/restore είναι απλούστερο και ασφαλέστερο από ένα CDC pipeline.

Αρχιτεκτονική

Πώς λειτουργεί

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

Trade-offs & αποτυχία

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