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

Debezium

Раздел03 · Механизмы · Примеры

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: Debezium 3.3.1.Final; PostgreSQL17, Oracle19c reference. Проверка источников: 2026-11-02; это не рекомендация latest release.

Архитектура и роль

FACT. CDC connectors читают согласованный initial snapshot и затем database change log, публикуя envelope changes. В классическом deployment выполняются внутри Kafka Connect; Debezium Engine/Server — другие embedding/deployment модели. CDC не является Event Sourcing и не создаёт отсутствующие domain facts.

Внутренние механизмы и движение данных

PostgreSQL connector использует logical decoding, publication и replication slot. Initial snapshot согласует snapshot с log position по protocol connector; наивный SELECT плюс текущий LSN теряет/дублирует переходы. Затем WAL changes преобразуются в before/after/op/source/ts metadata. Delete event и Kafka tombstone имеют разные назначения; потребитель обязан понимать оба.

Oracle connector имеет иной механизм: LogMiner либо поддерживаемый другой adapter читает redo, требует supplemental logging, privileges, archived redo и сохраняемую schema history. PostgreSQL WAL slot нельзя переносить в описание Oracle recovery. PG3.3, Oracle3.3.

flowchart TB
  PG[PostgreSQL snapshot and WAL slot] --> CDC[Connector-specific source protocol]
  Oracle[Oracle snapshot and redo mining] --> CDC
  CDC --> Envelope[Versioned change envelope]
  Envelope --> Kafka
  Kafka --> Sink[Idempotent current-state projection]

Ordering и guarantees

Обычный delivery contract допускает replay после restart. EOS source режим требует поддерживаемого connector/Connect configuration и не включает ClickHouse/Redis. Source transaction metadata помогает grouping, но произвольный sink не получает multi-table ACID. Snapshot op=r — baseline state, а не новая финансовая операция.

Документированный contract и версия.

Масштабирование и backpressure

Частота/размер source transactions, decoding CPU, WAL/redo IO, Kafka backpressure и snapshot scans ограничивают throughput. Incremental snapshots добавляют chunk/window protocol; это не простое независимое чтение pages. Параллелизм PostgreSQL logical stream не возникает из tasks.max=8.

Failure / recovery / replay

Сохранённые offsets должны указывать на ещё доступный log. Slot удерживает WAL и может угрожать primary disk; lost/invalidated slot требует согласованного bootstrap и reconciliation. Oracle archived redo gap/schema history loss также требует connector-specific recovery. Schema history topics не очищают обычной business retention policy.

Документированный contract и версия.

Эксплуатация и мониторинг

Мониторить snapshot state/progress, streaming lag и source log availability, retained WAL/redo, queue utilization, connector/task failures, schema-history availability и malformed envelopes. Учитывать long source transaction: latest emitted event может быть старым при живом connector. Перед failover проверить поддержку slot synchronization PG17 и connector baseline.

Ограничения и критерии выбора

DDL и schema evolution имеют source-specific ограничения. PostgreSQL logical protocol не является универсальным DDL stream; несовместимая change требует coordinated rollout target mapping/readers. Money decimal representation требует точного converter contract; преобразование decimal в float может испортить суммы.

FinTech / iGaming и реальные источники

INFERENCE: banking replication в analytics/AML inputs, betting corrections и outbox relay. Нельзя на snapshot ledger rows запускать повторные payouts. Banking walkthrough отдельно показывает PostgreSQL и Oracle paths; общий end-to-end contract не приписан компании.

Практический пример

CDC executable setup: PG17 schema, logical settings, connector registration/validation, snapshot затем updates/deletes. Oracle integration только документирована: database/license/redo environment не предоставлены.

Типичные ошибки проектирования

Удалять slot для снятия disk pressure без плана; трактовать snapshot как new business events; терять tombstones; конвертировать money в float; ожидать DDL migration всех sinks.

Вопросы на собеседовании

LSN — business version? Нет, это log position с scope/source semantics, не вечный aggregate sequence.

Повторный snapshot восстановит Event Sourcing history? Нет, текущий state не содержит все переходы.

Зачем supplemental logging Oracle? Log mining должен иметь нужную информацию для идентификации/восстановления изменений.

Практические упражнения

Измените schema, остановите connector, продолжите source writes и оцените log horizon. Запишите критерий rebootstrap и проверку counts/keys/amounts на согласованном cutoff.

Дополнительные источники