Миграция баз данных в облако: AWS DMS, Google DMS и Yandex Data Transfer

Перенос базы данных к облачному провайдеру редко сводится к выгрузке дампа. Если база большая, а простой допустим в минутах, нужен сервис, который сначала копирует данные, затем догоняет изменения, накопившиеся за время копирования, и держит копию в актуальном состоянии до момента переключения. У крупных облаков для этого есть собственные инструменты: AWS Database Migration Service, Google Cloud Database Migration Service и Yandex Data Transfer.

Как устроена миграция без долгого простоя

Почти все такие сервисы работают по одной схеме:

1. Начальное копирование — перенос существующих данных таблица за таблицей.
2. CDC (Change Data Capture) — чтение журнала изменений источника (WAL в PostgreSQL, binlog в MySQL, redo-журналы Oracle) и применение изменений на приёмнике, пока идёт копирование и после него.
3. Переключение — приложение ненадолго останавливают, дожидаются, пока приёмник догонит источник, и направляют приложение на новую базу.

Миграции делят на гомогенные (PostgreSQL → PostgreSQL) и гетерогенные (Oracle → PostgreSQL). Во втором случае, помимо данных, нужно перевести схему, процедуры и типы, и именно здесь сервисы различаются сильнее всего.

AWS Database Migration Service

Самый старый и универсальный из трёх. Работает в двух режимах:

• С репликационным инстансом — виртуальной машиной, которая читает источник и пишет в приёмник. Оплачивается по часам в зависимости от класса инстанса, плюс хранилище сверх включённого объёма.
• DMS Serverless — мощность подбирается автоматически и оплачивается в единицах DCU за час.

Для гетерогенных миграций есть DMS Schema Conversion: преобразование схемы и кода, например из Oracle или SQL Server в PostgreSQL. По странице тарифов AWS эта функция бесплатна, платить нужно только за хранилище S3, которое она использует.

Сильная сторона DMS — широкий выбор источников и приёмников и зрелая поддержка коммерческих СУБД. Слабая — нужно самостоятельно подбирать размер инстанса, следить за задачами и разбираться с тонкостями CDC для каждого источника.

Google Cloud Database Migration Service

Сервис рассчитан на перенос баз внутрь Google Cloud и работает без выделенных виртуальных машин: снимок данных и репликацию изменений Google берёт на себя.

По документации поддерживаются:

• гомогенные миграции — MySQL в Cloud SQL for MySQL, PostgreSQL в Cloud SQL for PostgreSQL и AlloyDB, SQL Server в Cloud SQL for SQL Server;
• гетерогенные — Oracle и SQL Server в Cloud SQL for PostgreSQL или AlloyDB с преобразованием схемы.

Главное ограничение — направление: сервис переносит данные в управляемые базы Google, а не между произвольными системами. Условия оплаты зависят от типа миграции, актуальные цифры — на странице тарифов сервиса.

Yandex Data Transfer

Сервис Yandex Cloud для переноса и постоянной репликации данных между базами, очередями и хранилищами. Поддерживает три типа трансфера: копирование, репликацию и копирование с последующей репликацией.

Источники по документации: PostgreSQL, MySQL, Oracle, MongoDB, ClickHouse, Greenplum, YDB, Apache Kafka, Data Streams, Object Storage, Elasticsearch, OpenSearch и другие. Приёмники: PostgreSQL, MySQL, MongoDB, ClickHouse, Greenplum, YDB, Kafka, Object Storage, Apache Iceberg, OpenSearch и другие. Не все сочетания источника и приёмника доступны, часть работает в режиме Preview.

Особенность Data Transfer — ориентация не только на переезд, но и на постоянные потоки: например, репликация из PostgreSQL в ClickHouse для аналитики или выгрузка изменений в Kafka.

Стоимость складывается из вычислительных ресурсов воркеров (vCPU и память по часам) и числа переданных строк; первые 100 млн строк в месяц не тарифицируются, трансферы в стадии Preview бесплатны.

Сравнение

Что доступно российской компании

• Оплата. Российской картой не оплатить ни AWS, ни Google Cloud: Visa и Mastercard не работают за рубежом с марта 2022 года, а Google Cloud не принимает новых клиентов из России.
• Персональные данные. С 1 июля 2025 года первичная запись персональных данных граждан России должна вестись в базах на территории России (подробнее о 152-ФЗ). Перенос такой базы в зарубежное облако этому требованию не соответствует.

Поэтому для российской компании реальный выбор — Yandex Data Transfer, аналогичные сервисы других российских облаков или самостоятельный перенос: логическая репликация PostgreSQL, репликация MySQL, pg_dump с последующим догоном изменений. Об устройстве этих СУБД — в статьях о MySQL и PostgreSQL.

Как подготовиться к миграции

1. Проверьте, что поддерживается ваш источник и нужный вариант CDC: для PostgreSQL обычно требуется wal_level = logical, для MySQL — binlog в формате ROW.
2. Сделайте пробный прогон на копии: время копирования, отставание репликации, объём изменений.
3. Сверьте данные после копирования — число строк и контрольные суммы по ключевым таблицам.
4. Проверьте то, что сервисы не переносят: пользователей и права, последовательности, триггеры, расширения.
5. Спланируйте переключение и откат: в какой момент останавливается запись, как долго ждать догона и как вернуться на старую базу, если что-то пойдёт не так.

Типичные ошибки

• Нет первичных ключей — CDC не может корректно применять изменения к таблице.
• Не учтено отставание репликации — переключение делается, когда приёмник ещё не догнал источник.
• Последовательности не синхронизированы — после переключения новые записи получают уже занятые идентификаторы.
• Экзотические типы и расширения при гетерогенной миграции без пробного прогона.
• Персональные данные перенесены за рубеж без оценки требований закона.