以前、Flywayで参照制約を追加したが、既存のデータが既に参照制約違反だったため、四苦八苦した話を書きました。

その後、色々知った後に検証をしていると、いろいろと勘違いしていることが分かったので、忘れないようにするためのメモ。タイトル自体は前回知りたかったことです。Flywayの公式のどこに書いてたんだろうか…。

なお、バックアップから復旧するよりはマシ、という内容なので、基本的には非推奨です。

誤って適用したバージョンをリセットする方法

バージョン管理テーブルとして、flyway_schema_historyテーブルが作成されています。その中に、今まで適用したバージョンがレコードとして登録されています。

完全にリセットしたい場合は、drop table flyway_schema_historyでリセットできます。installed_rankがインクリメントされていくので、リセットしたいバージョン以降のレコードを削除し、マイグレーションを行えば再適用できます。

ただし、この操作はFlywayでのステータスを適用から未適用に戻すだけです。Flywayで適用した結果は残るので、手動でDROP TABLEやALTER TABLE等で状態を戻す必要があります。

下記は検証した時の例。

installed_rank	version	description	type	script	checksum	installed_by	installed_on	execution_time	success
1	NULL	create table	SQL	R__create_table.sql	688335130	user	2020-10-18 13:13:12.540324	36	true
2	1	arien	SQL	V1__arien.sql	1672929557	user	2020-10-20 02:52:33.368014	57	true
3	NULL	create table	SQL	R__create_table.sql	695332486	user	2020-10-20 02:52:33.568768	51	true

その他自分の認識誤りだった点

Rファイルは起動するたびに実行される認識でした。そうではなく、checksumが同じ場合は変更が無いとみなし、1度しか実行されません。コメントやformatする等でファイルのchecksumが変更された時に再適用します。

なので、今後のプロジェクトでは下記のように管理しようと考えています。

以前はバージョン管理テーブルのflyway_schema_tableの存在を知りませんでした。なので、参照制約を追加したバージョンファイルが失敗するとレコードに履歴が書き込まれ、DBのスキーマ削除する必要があると考えていました。

しかし、検証した結果、どうやらFlywayでのマイグレーションに失敗した場合、そもそもレコードの登録が行われないようです。

つまり、flyway_schema_tableのレコードを修正することなく、ファイルを修正すれば問題ありません。

問題になるとしたら複数の環境に適用した後、特定の環境のみマイグレーションに失敗した時です。

冒頭に貼った記事は「review環境 → IT環境 → ST環境（ここで失敗）」という複数環境への適用後に失敗したので、flyway_schema_tableのレコードを削除して再適用する必要があります。

公式サイトは一応flyway_schema_tableのことは書いてあるものの、基本的にはコマンドしか書いておらず、自分で構築するまで気づけませんでした。しかも、gitbook等のように公式サイトを検索できないので、明示的にテーブルとして存在していることを見つけられなかったです。

基本的には一度でもFlywayの履歴を操作してしまうと、現在の状態を疑ってしまうので行いたくはないのですが、最終手段としてブログに残しておきます。

この記事がお役に立ちましたら、各種SNSでのシェアや、今後も情報発信しますのでフォローよろしくお願いします。

Flyway公式サイト flywaydb.org

Flyway公式サイト：修復する方法 flywaydb.org