Flywayを使用したデータベースの移行
1. 前書き
この記事では、Flywayの主要な概念と、このフレームワークを使用してアプリケーションのデータベーススキーマを確実かつ簡単に継続的に再構築する方法について説明します。 最後に、MavenFlywayプラグインを使用してインメモリH2データベースを管理する例を示します。
Flywayは、移行を使用してデータベースをあるバージョンから次のバージョンに更新します。 データベース固有の構文を使用したSQLまたは高度なデータベース変換のためのJavaで移行を記述できます。
移行は、バージョン管理または繰り返し可能です。 前者には固有のバージョンがあり、一度だけ適用されます。 後者にはバージョンがありません。 代わりに、チェックサムが変更されるたびに(再)適用されます。
単一の移行実行では、保留中のバージョン付き移行が実行された後、繰り返し可能な移行が常に最後に適用されます。 繰り返し可能な移行は、説明の順に適用されます。 単一の移行の場合、すべてのステートメントは単一のデータベーストランザクション内で実行されます。
この記事では、主にMavenプラグインを使用してデータベースの移行を実行する方法に焦点を当てます。
2. Flyway Mavenプラグイン
Flyway Mavenプラグインをインストールするには、次のプラグイン定義をpom.xml:に追加します。
org.flywaydb
flyway-maven-plugin
4.0.3
Maven repositoryで利用可能なプラグインの最新バージョンを確認できます。
このMavenプラグインは、4つの異なる方法で構成できます。 構成可能なすべてのプロパティのリストを取得するには、documentationを参照してください。
2.1. プラグイン構成
pom.xml:のプラグイン定義で<configuration>タグを使用して、プラグインを直接構成できます。
org.flywaydb
flyway-maven-plugin
4.0.3
databaseUser
databasePassword
schemaName
...
2.2. Mavenプロパティ
構成可能なプロパティをpom.xml:のMavenpropertiesとして指定することにより、プラグインを構成することもできます。
...
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. 移行の例
このセクションでは、Mavenプラグインを使用してデータベーススキーマをインメモリH2データベースに移行するために必要な手順を説明します。 外部ファイルを使用してFlywayを構成します。
3.1. POMを更新
pom.xml:にH2データベースの適切なデータベースドライバー依存関係を追加します
com.h2database
h2
1.4.196
Maven repositoryで入手可能な最新バージョンのドライバーを確認できます。 上記のセクション2で説明したように、Flywayプラグインをpom.xmlに追加します。
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ディレクトリにあることを指定しています。 databaseUserとdatabasePasswordを使用してメモリ内のH2インスタンスに接続します。
アプリケーションデータベーススキーマは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
作成するSQL命令を含むV1_0__create_employee_schema.sqlという名前の移行スクリプトを使用して、$PROJECT_ROOTにディレクトリdb/migrationを作成します。 従業員表:
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. 移行を実行する
$PROJECT_ROOTから次のMavenコマンドを呼び出して、データベースの移行を実行します。
$ mvn clean flyway:migrate -Dflyway.configFile=myFlywayConfig.properties
これにより、最初の移行が成功するはずです。 データベーススキーマは次のように表示されます。
employee:
+----+------+-------+---------------+
| id | name | email | date_of_birth |
+----+------+-------+---------------+
サブセクション3.3からの手順を繰り返します。 および3.4。 新しい移行を自由に定義して実行します。
3.5. 2回目の移行を定義して実行する
次の2つのクエリを含むV2_0_create_department_schema.sqlという名前の2番目の移行ファイルを作成します。
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で述べたのと同様の移行を実行します。 2回目の移行を正常に実行すると、データベーススキーマは次のようになります。
employee:
+----+------+-------+---------+---------------+
| id | name | email | dept_id | date_of_birth |
+----+------+-------+---------+---------------+
department:
+----+------+
| id | name |
+----+------+
次のMavenコマンドを呼び出すことで、両方の移行が実際に成功したことを確認できます。
$ mvn flyway:info -Dflyway.configFile=myFlywayConfig.properties
4. Flywayのしくみ
どの移行がいつ、誰によって適用されたかを追跡するために、スキーマに特別な簿記表を追加します。 このメタデータテーブルは、移行チェックサムと、移行が成功したかどうかも追跡します。
フレームワークは、進化するデータベーススキーマに対応するために次の手順を実行します。
-
データベーススキーマをチェックして、メタデータテーブル(デフォルトではSCHEMA_VERSION)を見つけます。 メタデータテーブルが存在しない場合は、作成します
-
利用可能な移行についてアプリケーションクラスパスをスキャンします
-
移行をメタデータテーブルと比較します。 バージョン番号が最新としてマークされたバージョン以下である場合、無視されます
-
残りの移行は保留中の移行としてマークされます。 これらはバージョン番号に基づいてソートされ、順番に実行されます
-
各移行が適用されると、それに応じてメタデータテーブルが更新されます
5. コマンド
Flywayは、データベースの移行を管理する次の基本的なコマンドをサポートしています。
-
Info:データベーススキーマの現在のステータス/バージョンを表示する。 保留中の移行、適用された移行、適用された移行のステータス、および適用された時期が出力されます。
-
Migrate:データベーススキーマを現在のバージョンに移行します。 利用可能な移行についてクラスパスをスキャンし、保留中の移行を適用します。
-
Baseline:baselineVersionを含むすべての移行を除いて、既存のデータベースをベースライン化します。 ベースラインは、既存のデータベースでFlywayを開始するのに役立ちます。 その後、新しい移行を正常に適用できます。
-
Validate:現在のデータベーススキーマを利用可能な移行に対して検証します。
-
Repair:メタデータテーブルを修復する。
-
Clean:構成されたスキーマ内のすべてのオブジェクトを削除します。 すべてのデータベースオブジェクトが削除されます。 もちろん、本番データベースではcleanを使用しないでください。
6. 結論
この記事では、Flywayがどのように機能し、このフレームワークを使用してアプリケーションデータベースを確実に再構築する方法を示しました。
この記事に付随するコードはGithubで入手できます。