cdc change data capture

CDC (Change Data Capture) — это паттерн и набор технологий для отслеживания и захвата изменений в базе данных (INSERT, UPDATE, DELETE) в реальном времени и передачи этих изменений в другие системы. CDC change data capture позволяет синхронизировать данные между системами без дорогостоящих full-dump репликаций и без нагрузки на источник.

Зачем нужен CDC

Традиционный подход к синхронизации данных — ночная batch-выгрузка: SELECT * FROM orders WHERE updated_at > last_run. Этот подход требует поля updated_at в каждой таблице, не улавливает DELETE, создаёт нагрузку на источник при больших объёмах и обеспечивает синхронизацию только раз в сутки.

CDC решает все эти проблемы: изменения захватываются в момент возникновения, DELETE отслеживается, нагрузка на источник минимальна, а задержка синхронизации снижается до секунд.

Как работает CDC на основе transaction log

Наиболее надёжный метод CDC — чтение transaction log (WAL) базы данных. Каждая реляционная СУБД ведёт журнал транзакций для восстановления после сбоев. CDC-система читает этот журнал и извлекает события изменений:

• PostgreSQL: logical replication с publication/subscription или через pgoutput/wal2json plugins
• MySQL: binlog (binary log) в row-based format
• SQL Server: встроенный CDC на основе transaction log или Change Tracking
• Oracle: LogMiner или Golden Gate
• MongoDB: Change Streams через oplog

Debezium — стандарт CDC

Debezium — open-source платформа CDC, работающая как набор Kafka Connect коннекторов. Debezium читает transaction log источника и публикует события изменений в Kafka-топики. Каждое событие содержит: тип операции (c=create, u=update, d=delete, r=snapshot), состояние до изменения (before), состояние после (after), метаданные транзакции.

Поддерживаемые источники: PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, Db2, Cassandra, Vitess. Стандарт де-факто для log-based CDC в open-source стеке.

Сценарии применения CDC

• Репликация в data warehouse — синхронизация операционных данных в Snowflake, BigQuery без bulk load
• Инвалидация кэша — автоматическое обновление Redis при изменении данных в БД
• Event sourcing — преобразование изменений в БД в event stream для event-driven архитектуры
• Поисковые индексы — синхронизация Elasticsearch/OpenSearch с основной БД
• Микросервисная синхронизация — передача изменений между сервисами без tight coupling
• Audit log — полная история всех изменений данных

Начальный снимок (snapshot)

При первом подключении CDC-система делает initial snapshot — полный снимок текущего состояния таблиц, после чего переключается на потоковое чтение изменений из log. Управление snapshot важно: для больших таблиц он может занимать часы, в течение которых изменения продолжают поступать в log.

Проблемы и ограничения CDC

Log-based CDC требует прав на чтение transaction log, что может быть ограничено в managed СУБД (хотя большинство поддерживают это: AWS RDS, Cloud SQL). Log retention нужно настраивать достаточным для работы CDC в случае отставания. Schema evolution — изменение схемы источника требует осторожной обработки: Debezium поддерживает schema history в отдельном топике Kafka.

Exactly-once семантика в CDC

Реализовать exactly-once в CDC-системе непросто. При сбое Debezium может переотправить часть уже обработанных событий. Консьюмер должен быть идемпотентным или использовать deduplication. Debezium гарантирует at-least-once доставку. Для exactly-once в Kafka Connect используют транзакции Kafka (Kafka Transactions API), доступные с Kafka 0.11. В sink-коннекторах идемпотентность реализуется через upsert вместо insert, или через хранение последнего обработанного offset в целевой системе. Outbox pattern — популярная альтернатива прямому CDC: приложение пишет события в специальную outbox-таблицу в той же транзакции, что и основные данные, а Debezium читает только outbox, гарантируя согласованность.