Перейти к содержанию

G. CDC connector restart во время snapshot

Раздел 04 · Failure matrix

Тип материала: учебный архитектурный сценарий. Не описывает систему конкретной компании. Все операции, IDs и числа ниже — HYPOTHETICAL.

Проверка источников: 2026-11-02. Интеграционный fault test этого сценария — NOT_RUN; documented behavior и предлагаемый recovery не считаются выполненным испытанием.

Normal flow

Debezium PostgreSQL connector 3.3, PG 17, Kafka Connect 4.1 как reference baselines. Initial snapshot и последующий WAL stream должны образовывать корректный source coverage по connector-specific protocol; совместный runtime baseline остаётся непроверенным. Snapshot read event — состояние строки, а не новая бизнес-команда.

Иллюстративная схема нормального пути:

flowchart LR
 P[PG snapshot and WAL retention] --> D[Debezium snapshot protocol]
 D --> K[Kafka records and connector progress]
 K --> S[Versioned row-state projection]

Failure timeline

sequenceDiagram
 participant P as PostgreSQL
 participant D as Debezium
 participant K as Kafka
 D->>P: Start initial snapshot
 P-->>D: Snapshot rows
 D->>K: Publish some read records
 Note over D: Restart before snapshot completion
 D->>K: Recover durable connector offsets
 D->>P: Resume or repeat per snapshot mode
 D->>K: Duplicate read records possible

Состояние систем после отказа

Участник Durable состояние Неопределённость / проверка
PostgreSQL Rows меняются; WAL/slot retained при достаточном месте Проверить slot continuity и retained WAL range
Connect Offsets/config/status topics имеют свои commits Не удалять их ради restart
Kafka/sink Часть snapshot read уже применена Нужен identity/state-upsert protocol для повторов

Retry и replay

Поведение interrupted snapshot определяется connector и mode; initial snapshot может повториться. Нельзя обещать continuation с последней строки для всех snapshot implementations. Read snapshot не должен повторно начислять баланс. Простое comparing Kafka offsets не разрешает source-order между snapshot и live row versions.

Обнаружение проблемы

Проверить connector tasks/status, snapshot markers, durable offsets, slot/WAL health, source coverage и target key counts на согласованном cut. Source row count при продолжающихся writes не является точным expected set без snapshot boundary.

Recovery protocol

  1. Сохранить connector config/offsets и replication slot evidence до restart.
  2. По документации выбранного snapshot mode определить repeat/resume semantics.
  3. Держать WAL до восстановления, ограничить исходящие projections, если completeness неизвестна.
  4. Применять snapshot state по business key и source-order protocol; повторы не превращать в новые financial events.
  5. При slot/log gap выбрать controlled resnapshot в новую generation; reconcile и cutover.
  6. Не переиспользовать старый inbox так, чтобы он пропустил все records новой projection.

Гарантии и trade-offs

Exactly-once business effect не выводится из успешного restart. При сохранных offsets/slot и поддержанном connector protocol возможен at-least-once recovery; sink обязан обработать повторы. Source-order адаптер, log-gap handling и real connector restart NOT_RUN.

Практическая проверка

Existing Debezium guide задаёт setup. В отдельном test namespace добейтесь достаточно большого snapshot, остановите task после видимого read batch, не удаляя offsets/slot, затем сравните covered keys. Не выдавайте ручную вставку read events за connector test.

Источники и версии