Миграция базы данных с Flyway

1. Вступление

В этой статье описываются ключевые концепцииFlyway и то, как мы можем использовать эту структуру для непрерывного надежного и легкого изменения схемы базы данных нашего приложения. В конце мы представим пример управления базой данных H2 в памяти с помощью плагина Maven Flyway.

Flyway обновляет базу данных с одной версии на другую с помощью миграций. Мы можем написать миграцию либо в SQL со специфическим синтаксисом базы данных, либо в Java для расширенных преобразований базы данных.

Миграции могут быть версионными или повторяемыми. Первая имеет уникальную версию и применяется ровно один раз. Последний не имеет версии. Вместо этого они (повторно) применяются каждый раз, когда изменяется их контрольная сумма.

В рамках одного прогона миграции повторяющиеся миграции всегда применяются в последнюю очередь после выполнения отложенных миграций с контролем версий. Повторяющиеся миграции применяются в порядке их описания. Для одной миграции все операторы выполняются в одной транзакции базы данных.

В этой статье мы в основном сосредоточимся на том, как мы можем использовать плагин Maven для выполнения миграции базы данных.

2. Плагин Flyway Maven

Чтобы установить плагин Flyway Maven, добавьте следующее определение плагина в свойpom.xml:


    org.flywaydb
    flyway-maven-plugin
    4.0.3

Вы можете проверить последнюю версию плагина, доступную наMaven repository.

Этот плагин Maven может быть настроен четырьмя различными способами. Пожалуйста, обратитесь кdocumentation, чтобы получить список всех настраиваемых свойств.

2.1. Конфигурация плагина

Мы можем настроить плагин напрямую, используя тег<configuration> в определении плагинаpom.xml:.


    org.flywaydb
    flyway-maven-plugin
    4.0.3
    
        databaseUser
        databasePassword
        
            schemaName
        
        ...

2.2. Свойства Maven

Мы также можем настроить плагин, указав настраиваемые свойства как Mavenproperties вpom.xml:


    ...
    
        databaseUser
        databasePassword
        schemaName
        ...
    
    ...

2.3. Внешний файл конфигурации

Мы также можем предоставить конфигурацию плагина в отдельном файле.properties:

flyway.user=databaseUser
flyway.password=databasePassword
flyway.schemas=schemaName
...

Имя файла конфигурации по умолчанию -flyway.properties, и он должен находиться в том же каталоге, что и файлpom.xml. Кодировка задаетсяflyway.encoding (по умолчаниюUTF-8).

Если вы используете любое другое имя (например,customConfig.properties) в качестве файла конфигурации, то его следует указать явно при вызове команды Maven:

$ mvn -Dflyway.configFile=customConfig.properties

2.4. Свойства системы

Наконец, все свойства конфигурации также могут быть указаны как системные свойства при вызове Maven из командной строки:

$ mvn -Dflyway.user=databaseUser -Dflyway.password=databasePassword
  -Dflyway.schemas=schemaName

Ниже приведен порядок приоритета, если конфигурация указана несколькими способами:

Свойства системы
Внешний файл конфигурации
Maven свойства
Конфигурация плагина

3. Пример миграции

В этом разделе мы рассмотрим необходимые шаги для переноса схемы базы данных в базу данных H2 в памяти с помощью плагина Maven. Мы используем внешний файл для настройки Flyway.

3.1. Обновить POM

Добавьте соответствующую зависимость драйвера базы данных для базы данных H2 вpom.xml:


    com.h2database
    h2
    1.4.196

Вы можете проверить последнюю версию драйвера, доступную наMaven repository. Добавьте плагин Flyway вpom.xml, как описано в разделе 2 выше.

3.2. Настроить Flyway с помощью внешнего файла

Создайте файлmyFlywayConfig.properties в$PROJECT_ROOT со следующим содержимым:

flyway.user=databaseUser
flyway.password=databasePassword
flyway.schemas=app-db
flyway.url=jdbc:h2:mem:DATABASE
flyway.locations=filesystem:db/migration

Приведенная выше конфигурация указывает, что наши сценарии миграции находятся в каталогеdb/migration. Он подключается к экземпляру H2 в памяти с помощьюdatabaseUser иdatabasePassword.

Схема базы данных приложения -app-db. Пожалуйста, заменитеflyway.user, flyway.password, flyway.url на ваше имя пользователя базы данных, пароль базы данных и хост / порт базы данных соответствующим образом.

3.3. Определить первую миграцию

Flyway придерживается следующего соглашения об именовании сценариев миграции:

<Prefix><Version>_ <Описание> .sql_

Куда:

<Prefix> - Префикс по умолчаниюV, который можно настроить в приведенном выше файле конфигурации с помощью свойстваflyway.sqlMigrationPrefix.
<Version> - Номер версии миграции. Основная и дополнительная версии могут быть разделены символомunderscore. Версия миграции всегда должна начинаться с 1.
<Description> - Текстовое описание миграции. Описание должно быть отделено от номеров версий двойным подчеркиванием.

Пример:V1_1_0__my_first_migration.sql

Создайте каталогdb/migration в$PROJECT_ROOT со сценарием миграции с именемV1_0__create_employee_schema.sql, содержащим инструкции SQL для создания, например. таблица сотрудников:

CREATE TABLE IF NOT EXISTS `employee` (

    `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `name` varchar(20),
    `email` varchar(50),
    `date_of_birth` timestamp

)ENGINE=InnoDB DEFAULT CHARSET=UTF8;

3.4. Выполнить миграции

Вызовите следующую команду Maven из$PROJECT_ROOT для выполнения миграции базы данных:

$ mvn clean flyway:migrate -Dflyway.configFile=myFlywayConfig.properties

Это должно привести к первой успешной миграции. Схема базы данных теперь может быть изображена следующим образом:

employee:
+----+------+-------+---------------+
| id | name | email | date_of_birth |
+----+------+-------+---------------+

Повторите шаги из подразделов 3.3. и 3.4. определять и запускать новые миграции по желанию.

3.5. Определить и выполнить вторую миграцию

Создайте второй файл миграции с именемV2_0_create_department_schema.sql, содержащий следующие два запроса:

CREATE TABLE IF NOT EXISTS `department` (

`id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
`name` varchar(20)

)ENGINE=InnoDB DEFAULT CHARSET=UTF8;

ALTER TABLE `employee` ADD `dept_id` int AFTER `email`;

Выполните миграцию, аналогичную упомянутой в разделе 3.4 выше. Схема базы данных выглядит следующим образом после успешного выполнения второй миграции.

employee:
+----+------+-------+---------+---------------+
| id | name | email | dept_id | date_of_birth |
+----+------+-------+---------+---------------+

department:
+----+------+
| id | name |
+----+------+

Теперь мы можем проверить, что обе миграции действительно были успешными, вызвав следующую команду Maven:

$ mvn flyway:info -Dflyway.configFile=myFlywayConfig.properties

4. Как работает пролетный путь

Чтобы отслеживать, какие миграции уже были применены, когда и кем, он добавляет специальную таблицу учета в вашу схему. Эта таблица метаданных также отслеживает контрольные суммы миграции и определяет, были ли миграции успешными.

Платформа выполняет следующие шаги, чтобы приспособиться к развивающимся схемам базы данных:

Он проверяет схему базы данных, чтобы найти ее таблицу метаданных (по умолчаниюSCHEMA_VERSION). Если таблица метаданных не существует, она создаст
Сканирует путь к классу приложения на предмет доступных миграций.
Он сравнивает миграции с таблицей метаданных. Если номер версии меньше или равен версии, помеченной как текущая, она игнорируется
Любые оставшиеся миграции отмечаются как ожидающие миграции. Они отсортированы по номеру версии и выполняются в порядке
Поскольку каждая миграция применяется, таблица метаданных обновляется соответственно

5. команды

Flyway поддерживает следующие основные команды для управления миграцией базы данных.

Info: Выводит текущий статус / версию схемы базы данных. Он печатает, какие миграции ожидают, какие миграции были применены, каков статус примененных миграций и когда они были применены.
Migrate: Переносит схему базы данных в текущую версию. Он сканирует путь к классам для доступных миграций и применяет ожидающие миграции.
Baseline: Базовый уровень существующей базы данных, исключая все миграции, включаяbaselineVersion. Базовая линия помогает начать с Flyway в существующей базе данных. Новые миграции могут быть применены в обычном режиме.
Validate: Проверяет текущую схему базы данных на предмет доступных миграций.
Repair: Исправляет таблицу метаданных.
Clean: Удаляет все объекты в настроенной схеме. Все объекты базы данных удалены. Конечно, вы никогда не должны использовать clean в любой производственной базе данных.

6. Заключение

В этой статье мы показали, как работает Flyway и как мы можем использовать эту структуру для надежной модернизации базы данных нашего приложения.

Код, сопровождающий эту статью, доступен наGithub.

TOC

Миграция базы данных с Flyway