Kako CDC sinhronizira podatke čez sisteme?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** pretaka vsak insert/update/delete iz izvorne podatkovne baze — običajno z **branjem njenega transakcijskega dnevnika** — in jih objavlja kot dogodke, ki jih drugi sistemi konzumirajo, tako da nižje shrambe ostanejo sinhronizirane brez dvojnih zapisov ali poizvedovanja (polling).

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

## Zakaj CDC na osnovi dnevnika

Sinhronizirate lahko s poizvedovanjem ("vrstice, spremenjene od T") ali z zapisovanjem v dva sistema hkrati (**dvojni zapis / dual-write**), a poizvedovanje zgreši hitre posodobitve, dvojni zapisi pa se lomijo atomarno — če drugi zapis odpove, dobite razhajanje. **CDC na osnovi dnevnika** namesto tega sledi lastnemu write-ahead dnevniku podatkovne baze (Postgres **WAL**, MySQL **binlog**), trajnemu zapisu, ki ga DB uporablja za okrevanje po sesutju. **Debezium** je standardni konektor: bere dnevnik in objavlja vsako spremembo v **Kafko**, en topic na tabelo — zajame *vsako* spremembo brez obremenitve poizvedb in brez zgrešenih vrstic.

## Urejanje in idempotenca

- **Urejanje (ordering):** spremembe iste vrstice morajo prispeti po vrsti, sicer bi zadnjo uveljavili staro vrednost. Kafka jamči vrstni red **znotraj particije**, zato particionirajte po primarnem ključu — vse spremembe za eno vrstico pristanejo na eni particiji, v vrstnem redu potrditve (commit).
- **Dostava je at-least-once:** ob ponovnem poskusu ali ponovnem zagonu konektorja se lahko isti dogodek dostavi dvakrat. Zato **morajo biti sinki idempotentni** — ključite zapis po primarnem ključu + odmiku dnevnika (LSN), tako da je ponovna uveljavitev dogodka brez učinka (no-op). Nikoli ne predpostavljajte exactly-once.

## Pogled s stališča razgovora

Izpraševalec preverja, ali veste, da CDC premaga dvojne zapise in *zakaj* (atomarnost, brez zgrešenih sprememb), in ali dojamete **at-least-once + idempotentne sinke**. Dobro: "Debezium bere WAL v Kafko." Odlično: dodate particioniranje po ključu za urejanje in idempotentne sinke za dvojnike. Past: domneva exactly-once dostave ali ignoriranje, da lahko DDL sprememba na viru zlomi consumerje.

## Kompromisi in načini odpovedi

- **Evolucija sheme:** dodan/odstranjen stolpec navzgor spremeni obliko dogodka — uporabite **schema registry** in združljive spremembe, da se consumerji ne zlomijo.
- **Začetni posnetek (initial snapshot):** CDC vidi le spremembe *odslej*; potrebujete enkraten posnetek obstoječih vrstic, nato preklopite na pretakanje.
- **Hramba dnevnika:** če vir počisti svoj dnevnik, preden ga konektor prebere, izgubite spremembe — nadzorujte zaostanek konektorja.
- **Protipritisk (backpressure):** počasen sink pusti Kafka zaostanek rasti; dimenzionirajte hrambo in consumerje za vršni obseg sprememb.

Zakaj CDC na osnovi dnevnika

Urejanje in idempotenca

Pogled s stališča razgovora

Kompromisi in načini odpovedi

Povezana vprašanja