Binlog может рассказать, что изменилось в MySQL. Но он не обязан рассказывать, зачем это изменение произошло

MySQL широко используется внутри сайтов, сервисов, интернет-магазинов и корпоративных приложений. Поэтому запрос на интеграцию часто звучит просто: «Нам нужно забирать изменения из базы». Технически это может быть вполне решаемо. Архитектурно сначала нужно понять, нужен ли другой системе поток данных, бизнес-событие, read model или возможность выполнять бизнес-операцию. AMPE разделяет эти задачи до выбора механизма.

Начать диагностику

Replication — это механизм распространения изменений, а не универсальный integration API

MySQL replication основана на binary log: source фиксирует изменения, replica получает и применяет их.

Это отлично подходит для задач отказоустойчивости, чтения, миграции и ряда data-интеграционных сценариев.

Но replica наследует структуру исходной модели.

Она не превращает внутренние таблицы приложения в устойчивый публичный контракт.

Если внешней системе нужна бизнес-функция, API всё ещё может быть правильнее.

Binlog даёт сильную основу для CDC

Изменения INSERT / UPDATE / DELETE могут быть получены из журнала и переданы в downstream-контур.

AMPE проектирует весь lifecycle потока, а не только первый успешный capture.

Это позволяет
не сканировать таблицы целиком; снижать задержку; строить аналитические потоки; синхронизировать поисковый индекс; передавать изменения в DWH или event pipeline.
Но вместе с CDC появляются вопросы, которых нет у обычного SELECT
позиция чтения; повторная обработка; порядок; schema changes; initial snapshot; восстановление consumer после остановки.

Gtid упрощает идентификацию транзакций в replication-топологии

В инфраструктуре с replication важно устойчиво понимать, какие транзакции уже применены и где находится replica.

GTID-based подход может упростить переключения и управление топологией по сравнению с ручной ориентацией только на file / position.

Но наличие GTID не решает бизнес-дедупликацию между приложениями.

Техническая уникальность транзакции и уникальность внешнего заказа — разные уровни.

Row-based и statement-based logging не нужно воспринимать как косметическую настройку

Формат binlog влияет на то, что именно получает downstream и как воспроизводятся изменения.

Для CDC особенно важно понимать реальный формат событий и ограничения конкретной конфигурации.

AMPE проверяет это до проектирования consumer, а не после того, как pipeline уже написан вокруг неверных предположений.

Read replica может отделить аналитическое чтение от основной нагрузки — но у неё есть lag

Пользователь только что изменил данные в primary.

Отчёт прочитал replica.

Изменение ещё не доехало.

Оба компонента работают правильно, но пользователь видит «старую правду».

Поэтому AMPE отдельно определяет, для каких сценариев eventual read допустим, а где после записи требуется читать authoritative state.

Прямая запись в чужую MySQL-базу может быть технически простой и бизнесово неверной

Таблица orders существует.

Можно сделать INSERT.

Если интеграция обходит этот слой, она создаёт запись, которая выглядит корректно только на уровне БД.

Мы не считаем доступ к таблице доказательством правильной точки записи.

Но приложение могло ожидать
валидацию; расчёт цены; создание дочерних объектов; event publication; обновление индекса; аудит.

Incremental polling и CDC — не одно и то же

Иногда полноценный binlog pipeline не нужен.

Если таблица маленькая, задержка в несколько минут допустима, а изменения имеют надёжный monotonically increasing ID или updated_at, incremental polling может быть проще и дешевле.

Но он требует аккуратной работы с окнами времени, повтором и late updates.

AMPE не добавляет сложность ради «настоящего real-time» там, где бизнес её не использует.

Initial snapshot — часть интеграции, которую легко недооценить

CDC начинает передавать новые изменения.

Но downstream ещё не знает старое состояние.

Нужна стартовая загрузка и точка, после которой snapshot и поток изменений сходятся без пропусков и дублей.

Именно на этой границе многие «простые» data pipelines становятся сложными.

AMPE проектирует bootstrap и steady state как одну систему.

MySQL ↔ DWH — это не просто copy table

Операционная модель оптимизирована под работу приложения.

Поэтому ingestion и analytical model — разные слои.

Мы не переносим случайную структуру production один в один и не называем это архитектурой данных.

Аналитике может понадобиться
история; другая гранулярность; объединение с другими источниками; стабильные business keys; SCD; очистка и нормализация.

MySQL ↔ поиск / cache / secondary store: важно понимать, как восстановить производную систему

Если Elasticsearch, Redis или другой secondary store является производной от MySQL, его можно и нужно уметь восстановить из authoritative source.

Это сильно меняет требования к двусторонней синхронизации.

Производный индекс не должен становиться второй истиной случайно.

Что мы проверяем перед интеграцией MySQL

Кому принадлежит база.

Можно ли читать production напрямую.

Какой engine и transaction model критичны для сценария.

Как настроен binary log.

Нужен ли CDC вообще.

Допустим ли replica lag.

Как меняется schema.

Как downstream переживает replay.

Что считается уникальной бизнес-операцией.

Как обнаружить расхождение после сбоя.

Хороший результат не выглядит как «мы подключились к MySQL»

Он выглядит так:

данные выходят из операционной системы без ручных экспортов;

production не страдает от чужой нагрузки;

consumer может восстановиться после остановки;

повтор не создаёт дубликат;

schema change не ломает поток молча;

а внешняя система получает именно тот уровень данных, который ей действительно нужен.

Первый шаг

С чего начать

«Нам нужно, чтобы изменения из MySQL автоматически попадали в другую систему». Следующий вопрос AMPE будет не «какой connector поставить», а «какие именно изменения и зачем нужны другой системе». От этого и строится правильная архитектура.