Как проходили миграции

Миграции в Java проектах

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

Инструменты и фреймворки

В большинстве Java проектов используются специализированные инструменты:

• Flyway — самый популярный выбор, работает с версионированием миграций, простой и надёжный
• Liquibase — более гибкий, поддерживает различные форматы (SQL, XML, YAML)
• Hibernate с аннотациями — для небольших проектов, но не рекомендуется для production

Типовой процесс миграции

Фаза подготовки:

1. Создание миграционного скрипта с версией (например, V1_2_3__add_user_status.sql)
2. Тестирование на копии production базы
3. План отката (DOWN скрипт или резервная копия)
4. Измерение времени выполнения

Фаза выполнения:

public class UserMigration {
    // Flyway автоматически запустит все новые миграции
    // При старте приложения проверяется версия БД
    // Если версия < текущей, запускаются недостающие скрипты
}

Миграция данных с преобразованиями:

// migration/V2__migrate_user_data.sql
ALTER TABLE users ADD COLUMN status VARCHAR(50);
UPDATE users SET status = 'active' WHERE created_at > NOW() - INTERVAL 30 DAY;
ALTER TABLE users DROP COLUMN old_status;

Практический пример

Основной конфиг Flyway в Spring Boot:

@Configuration
public class FlywayConfig {
    @Bean
    public Flyway flyway(DataSource dataSource) {
        return Flyway.configure()
            .dataSource(dataSource)
            .locations("classpath:db/migration")
            .baselineOnMigrate(true)
            .load();
    }
}

Сложные сценарии

Миграция с нулевым простоем:

• Добавляем новый столбец как nullable
• Развертываем код, который пишет в обе колонки
• Копируем данные в фоне
• Удаляем старую колонку
• Делаем новую обязательной

Откат миграции:

• Flyway не поддерживает автоматический откат (это feature, не баг)
• Откат делается явно или откатом кода + явным скриптом
• Для каждой прямой миграции готовим скрипт отката

Проблема N+1 при миграции данных:

// Плохо: N+1 queries
List<User> users = userRepository.findAll();
for (User user : users) {
    user.setStatus("active");
    userRepository.save(user);
}

// Хорошо: batch update
userRepository.updateStatusForActiveUsers("active");

Мониторинг и безопасность

1. Версионирование: каждая миграция имеет уникальный номер
2. Checksum: Flyway проверяет, что миграция не менялась
3. Логирование: все миграции логируются с временем выполнения
4. Откат: всегда готовим план отката
5. Тестирование: локально, на staging, затем на production

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

• Забыли про существующие данные
• Миграция занимает часы и блокирует базу
• Нет плана отката
• Разные SQL диалекты на разных BD (Oracle vs PostgreSQL)
• Забыли про индексы и foreign keys

Корректная подготовка и пошаговое выполнение — залог успешной миграции без потерь данных и downtime.