Hogyan szinkronizál a CDC adatot rendszerek között?

Question

IT Interview Practice · Accepted Answer

A **Change Data Capture (CDC)** minden insertet/update-et/delete-et kistreamel egy forrás adatbázisból — jellemzően a **tranzakciós logja olvasásával** — és eseményekként publikálja, amelyeket más rendszerek fogyasztanak, így a downstream store-ok szinkronban maradnak dual-write vagy pollozás nélkül.

```text
  Postgres/MySQL          Debezium            Kafka topic          sinks
 ┌────────────┐  reads   ┌─────────┐  emit   ┌──────────┐  consume ┌───────────┐
 │ WAL/binlog │ ───────▶ │ connector│ ──────▶ │ per-table│ ───────▶ │ search    │
 │ (tx log)   │          │          │  events │  ordered │          │ warehouse │
 └────────────┘          └─────────┘          └──────────┘          │ cache     │
                                                                     └───────────┘
```

## Miért log-alapú CDC

Szinkronizálhatnál pollozással ("T óta változott sorok") vagy két rendszerbe egyszerre írással (**dual-write**), de a pollozás lemarad a gyors frissítésekről és a dual-write-ok atomian törnek — ha a második írás meghiúsul, szétválást kapsz. A **log-alapú CDC** ehelyett az adatbázis saját write-ahead logját követi (Postgres **WAL**, MySQL **binlog**), a tartós rekordot, amit a DB crash recoveryhez használ. A **Debezium** a standard connector: olvassa a logot és minden változást a **Kafkába** publikál, egy topic táblánként — *minden* változást elkapva, a lekérdezésekre terhelés és kihagyott sorok nélkül.

## Sorrend és idempotencia

- **Sorrend:** ugyanazon sor változásainak sorrendben kell érkezniük, különben egy régi értéket alkalmaznál utoljára. A Kafka garantálja a sorrendet **egy partíción belül**, ezért partícionálj elsődleges kulcs szerint — egy sor minden változása egy partícióra kerül, commit sorrendben.
- **A kézbesítés at-least-once:** egy retrynél vagy connector újraindításnál ugyanaz az esemény kétszer is kézbesíthető. Ezért a **sinkeknek idempotenseknek kell lenniük** — kulcsold az írást elsődleges kulcs + log offset (LSN) szerint, hogy egy esemény újraalkalmazása no-op legyen. Sose feltételezz exactly-once-t.

## Interjú szemszög

Az interjúztató azt ellenőrzi, tudod-e, hogy a CDC veri a dual-write-okat és *miért* (atomicitás, nincs kihagyott változás), és felfogod-e az **at-least-once + idempotens sinkeket**. Jó: "a Debezium olvassa a WAL-t a Kafkába." Kiváló: hozzáadod a partícionálást kulcs szerint a sorrendhez és az idempotens sinkeket a duplikátumokhoz. Csapda: exactly-once kézbesítést feltételezni, vagy figyelmen kívül hagyni, hogy egy DDL változás a forráson eltörheti a consumereket.

## Kompromisszumok és hibamódok

- **Séma-evolúció:** egy upstream hozzáadott/eldobott oszlop megváltoztatja az esemény alakját — használj egy **schema registryt** és kompatibilis változtatásokat, hogy a consumerek ne törjenek el.
- **Kezdeti snapshot:** a CDC csak *mostantól* látja a változásokat; egy egyszeri snapshotra van szükséged a meglévő sorokról, majd váltás streamingre.
- **Log retention:** ha a forrás kipurgálja a logját, mielőtt a connector olvassa, elveszíted a változásokat — monitorozd a connector laget.
- **Backpressure:** egy lassú sink hagyja a Kafka laget nőni; méretezd a retentiont és consumereket a csúcs változásvolumenre.

Miért log-alapú CDC

Sorrend és idempotencia

Interjú szemszög

Kompromisszumok és hibamódok

Kapcsolódó kérdések