Термин «миграция» в IT используется в нескольких совершенно разных контекстах. Новички (и иногда опытные разработчики) часто путают миграции баз данных, миграции кода/инфраструктуры и миграции данных. Статья поможет разобраться в видах миграций и понять, какой инструмент или подход выбрать для вашей задачи.
Миграции схемы базы данных (Schema Migrations) — самый частый сценарий
Когда разработчики говорят «запусти миграции», в 90% случаев речь идет именно об этом. Это версионированные скрипты, которые изменяют структуру БД: создают таблицы, добавляют колонки, индексы, внешние ключи.
Как определить, что это именно то, что нужно:
- Вы меняете структуру таблиц (DDL: CREATE, ALTER, DROP).
- Вам нужно, чтобы изменения применялись по порядку и только один раз на каждой среде (dev, stage, prod).
- Вам важен откат (rollback) в случае ошибки.
- Команда работает с Git: миграции хранятся в репозитории рядом с кодом.
Популярные инструменты:
- Flyway / Liquibase — стандарт де-факто для Java/Spring, но работают и отдельно (CLI, Docker). Поддерживают SQL и XML/YAML/JSON форматы.
- Alembic — стандарт для Python (SQLAlchemy).
- Entity Framework Migrations / EF Core — для .NET.
- TypeORM / MikroORM / Prisma Migrate — для Node.js / TypeScript.
- Goose / sql-migrate / Atlas, для Go.
- ActiveRecord Migrations — для Ruby on Rails.
Ключевые признаки правильной миграции схемы:
- Идемпотентность (желательно): повторный запуск не ломает БД (например,
CREATE TABLE IF NOT EXISTSили проверка существования колонки). - Атомарность: одна миграция — одна логическая задача (не мешайте создание таблицы пользователей и добавление индекса к логам в один файл).
- Нейминг:
V1.0.1__create_users_table.sql(Flyway) или20231027120000_create_users.py(Alembic).
Миграции данных (Data Migrations) — меняем содержимое, не структуру
Часто путают со схемой. Если вы заполняете справочник, шифруете пароли, переносите данные из колонки full_name в first_name + last_name, это миграция данных.
Как отличить и как делать правильно:
- Отдельные файлы: Не смешивайте DDL (схему) и DML (данные) в одной миграции. Сначала миграция схемы (добавили колонку), потом миграция данных (заполнили её), потом, возможно, еще одна схема (сделали колонку NOT NULL).
- Производительность: На больших таблицах (миллионы строк) обычный
UPDATEзаблокирует таблицу надолго. Используйте батчи (chunks),pt-online-schema-change(Percona) или логику в приложении (backfill job). - Откат: Откат данных часто невозможен без бэкапа. Документируйте это.
Миграция между СУБД (Database Migration / Replication)
Это задача DevOps/Инженеров по данным: перенос с PostgreSQL на MySQL, с On-premise в Cloud (AWS RDS, Cloud SQL), с Oracle на PostgreSQL.
Признаки этой задачи:
- Меняется движок хранения.
- Требуется репликация (CDC — Change Data Capture) для нулевого даунтайма.
- Нужна конвертация типов данных, синтаксиса SQL, процедур.
Инструменты:
- AWS DMS / Azure Database Migration Service / Google Database Migration Service — облачные сервисы.
- Debezium + Kafka — для построения собственного CDC пайплайна.
- pgloader, ora2pg, mysql2pgsql — утилиты для разовых переносов.
- Flyway / Liquibase — часто используют для генерации схемы в новой БД перед переносом данных.
Миграция кода и инфраструктуры (Application / Infrastructure Migration)
В широком смысле это перенос приложения: с монолита на микросервисы, с VM на Kubernetes, с Java 8 на Java 21, с собственного дата-центра в AWS.
Как определить подход:
- Strangler Fig Pattern (Удушающая смоковница): Постепенная замена частей монолита новыми сервисами. Подходит для крупных систем.
- Lift and Shift (Рехостинг): Перенос «как есть» в облако. Быстро, но не дает выгоды cloud-native.
- Refactoring / Replatforming: Адаптация кода под новую платформу (например, замена файловой системы на S3).
- Blue/Green / Canary Deployment: Стратегии переключения трафика при миграции версий приложения.
Чек-лист: «Какая миграция мне нужна?»
Ответьте на вопросы, чтобы выбрать направление:
| Вопрос | Если «Да» → Ваш вариант |
|---|---|
| Я добавляю/удаляю колонки, таблицы, индексы в текущей БД? | Миграция схемы (Schema Migration). Выберите инструмент под ваш стек (Flyway, Alembic, EF Core). |
| Мне нужно заполнить новые колонки значениями, пересчитать кэши, очистить мусор? | Миграция данных (Data Migration). Пишите отдельные скрипты, думайте о батчах и блокировках. |
| Мы переезжаем с PostgreSQL на MySQL / в облако / с Oracle? | Миграция СУБД (Database Migration). Нужен CDC (Debezium, DMS) и тщательное тестирование совместимости типов. |
| Меняем язык, фреймворк, архитектуру, хостинг? | Миграция приложения/инфраструктуры. Планируйте по Strangler Fig или Blue/Green. |
Best Practices для любых миграций
- Версионируйте всё. Даже если мигрируете данные скриптом на Python — положите его в Git с префиксом версии/даты.
- Тестируйте на копии продакшена. Используйте снапшоты БД (RDS snapshots, pg_basebackup) для репетиции.
- Автоматизируйте в CI/CD. Миграции схемы должны накатываться автоматически при деплое (с гейтом на ручное подтверждение для продакшена);
- План отката (Rollback Plan). Всегда имейте ответ на вопрос: «Что делаем, если это сломало продакшн через 10 минут?». Для схем —
DOWNмиграции. Для данных — бэкап. Для СУБД — репликация в обратную сторону. - Наблюдаемость. Логируйте начало/конец миграции, засекайте время, мониторьте локи БД (pg_locks, SHOW PROCESSLIST).
- Если меняете структуру таблиц в текущем проекте — вам нужны Schema Migrations (Flyway, Alembic, EF Migrations).
- Если меняете данные внутри таблиц — пишите Data Migrations (отдельно от схемы, с учетом производительности).
- Если меняете саму базу данных или облако — это проект Database Migration (DMS, Debezium, pgloader).
- Если меняете код/архитектуру/хостинг, это Application Migration (Strangler Fig, K8s, Blue/Green).
Резюме
«Магирани» (миграции) — это процесс управления изменениями.
Определите контекст вашей задачи по этой классификации, и выбор инструмента станет очевидным.