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

CDC snapshot, WAL/binlog и schema evolution

Глубокие темы · Раздел03

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

Версии в источниках: Kafka/Connect/Streams 4.1, Debezium 3.3, Flink 1.20.3, Spark 4.0.1 и Airflow 3.1 либо явно названная система. Непроверенные вопросы и ограничения runtime — в журнале (архив рабочего проекта).

Механизм

Snapshot строит baseline state; log capture продолжает changes без неопределённого gap по protocol конкретного connector. PostgreSQL WAL/logical slot, MySQL binlog и Oracle redo/schema history различаются по formats, retention и failover.

flowchart TB
  Snapshot[Consistent baseline] --> Envelope[Versioned CDC envelope]
  Log[Retained WAL binlog or redo] --> Envelope
  Envelope --> Mapping[Keys decimals deletes and schema]
  Mapping --> Target[Target projection]
  Target --> Reconcile[Explicit-cut reconciliation]

Пошаговое объяснение

Зафиксировать source identity/log position и согласованный snapshot → emit baseline rows как op=r → stream committed changes → map keys/types/deletes → checkpoint progress → reconcile target at explicit cutoff. Connector incremental snapshot имеет chunk/window protocol; чтение произвольных pages не эквивалентно ему.

Failure scenarios и recovery

Log gap после outage нельзя залатать latest state, сохранив утраченную полную history. Snapshot как команды финансовых effects недопустим. DDL rollout: сохранить old/new schema version, научить readers, изменить source, обновить target mapping и проверить missed deletes/precision.

Trade-offs и эксплуатация

Exact decimal, timezone и null/delete semantics важнее просто valid JSON. Schema Registry structural compatibility не доказывает semantic compatibility units/currency. Oracle supplemental logging и redo permissions могут быть prerequisites; PG17 slot failover требует отдельной настройки.

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

PostgreSQL CDC sample и Banking CDC. Oracle runtime/schema history test остаётся NOT_RUN.

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

Смешивать source/state/sink boundaries, скрывать failed records и неопределённый исход timeout; применять retry без identity/version и retention contract. Конкретные ограничения разобраны выше.

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

CDC равно Event Sourcing? Нет, изменённые storage rows не гарантируют domain intent/history.

Восстановить slot достаточно? Нужны правильные offsets, retained log и consistent target baseline.

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

Спроектируйте ADD nullable field, rename и numeric precision change для source→Kafka→CH. Для каждой опишите incompatible reader и rollback.

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