Почему миграция БД может не пройти?

Почему миграция БД может не пройти?

Миграция базы данных — критический процесс, и существует множество причин, по которым она может завершиться неудачей. Давайте разберёмся в основных сценариях.

Причины отказа миграций

1. Нарушение целостности данных

Одна из самых частых причин — конфликт между новой схемой и существующими данными:

• NOT NULL constraint: попытка добавить столбец NOT NULL без значения по умолчанию к таблице с данными
• Уникальные ограничения: добавление UNIQUE индекса к столбцу с дубликатами значений
• Foreign Key нарушения: удаление родительской таблицы при наличии сирот
• Проверочные ограничения: новое CHECK ограничение не удовлетворяется для существующих записей

// Пример: миграция добавляет NOT NULL столбец
// ALTER TABLE users ADD COLUMN email VARCHAR(255) NOT NULL;
// ОШИБКА: существующие строки не имеют значения email

2. Проблемы с заблокированными ресурсами

Духовод БД может быть недоступен или заблокирован:

• Активные соединения: другие процессы используют таблицы
• Блокировки на уровне БД: долгие транзакции предыдущих миграций
• Недостаточные привилегии: пользователь миграций не имеет прав на ALTER TABLE
• Тайм-ауты: операция DDL превышает лимит времени

3. Синтаксические и логические ошибки в SQL

// Неверный синтаксис
// CREATE TABLE users (
//   id INT PRIMARY KEY,
//   name VARCHR(255)  // Опечатка: VARCHR вместо VARCHAR
// );

// Неправильная последовательность
// ALTER TABLE orders DROP COLUMN user_id;
// ALTER TABLE orders ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id);
// ОШИБКА: столбец уже удалён

4. Проблемы с индексами и производительностью

• Создание индекса на большой таблице: может зависнуть или исчерпать память
• Конфликты имён: попытка создать индекс, который уже существует
• Индексы для новых ограничений: автоматический индекс может быть недоступен

5. Версионирование и совместимость

• Разные версии СУБД: синтаксис PostgreSQL не работает в MySQL
• Отсутствие зависимостей: миграция зависит от функции, которая не была создана
• Откат и переупорядочение: попытка применить миграцию, которая уже откачена

// Зависимость между миграциями
// V001__create_users.sql
// V002__add_age_column.sql  // Требует таблицы users
// V003__create_orders.sql   // Требует users для foreign key

6. Проблемы с окружением и конфигурацией

• Неправильная строка подключения: база не существует или пароль неверный
• Пути к файлам миграций: фреймворк не находит .sql файлы
• Кодировка: файлы в UTF-8, а БД ожидает Latin1
• Разные БД на разных стадиях: dev отличается от prod

Стратегии предотвращения

1. Тестирование миграций:

// Использование Flyway/Liquibase с тестовыми базами
// Запуск миграций в изолированных окружениях
// Проверка откатов: V001.sql → откат → V001.sql

2. Идемпотентность:

-- Вместо: CREATE TABLE users (...);
-- Используйте: CREATE TABLE IF NOT EXISTS users (...);

3. Постепенные изменения:

-- Вместо одной большой миграции
-- Разделите на несколько шагов:
-- 1. Добавить столбец с дефолтом
-- 2. Заполнить данные
-- 3. Добавить NOT NULL ограничение

4. Мониторинг и логирование:

// Использование инструментов как flyway-maven-plugin с подробными логами
// Отслеживание времени выполнения каждой миграции
// Документация каждого изменения с объяснением

Отладка при сбое

Если миграция завершилась неудачей:

1. Проверить логи: детальные сообщения об ошибках
2. Проверить состояние БД: какие таблицы были созданы
3. Откатить вручную: удалить или зафиксировать проблемные объекты
4. Пересоздать историю миграций: в некоторых инструментах требуется обновление таблицы schema_version

Миграции — это не просто код, это контракт между приложением и хранилищем данных. Каждый шаг должен быть тщательно спланирован и протестирован.