flyway_schema_historyテーブルのinstalled_onに入る日時
データベースのマイグレーションツールである flyway。
あまりマイグレーションツールは好きではないのですが、チームで開発する上では避けて通れないところ。
flyway では、テーブルに対する変更のバージョン管理を flyway_schema_history というテーブルで管理しています。
しかし、このテーブルに設定される各カラムの詳細な説明がドキュメントサイトでもなかなか見つからない。
今回は installed_on の項目について調べてみたので紹介していきます。
flywayのドキュメント
flyway のドキュメントサイトは以下の通り。
flyway_schema_history テーブルに関連しそうなページだと、下記の Table のところになるでしょうか。
ただ、このテーブルのカラムの項目について詳しく説明しているページがなさそうなのですよね。
そこで、GitHub でコードを確認してみるしかない。
MySQL用のテーブル
以下のソースコードが、テーブル構築などのクエリに該当しそうな感じです。
これによると、「installed_on」のデフォルト値は CURRENT_TIMESTAMP となっていますね。
`installed_on` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
よって、flyway の実行開始日時ではなく、完了日時が入るようです。
実行時間自体は「execution_time」にミリ秒が入ってくることは確認できているので、これらのカラムの値から、実行開始日時と完了日時が割り出せますね。
Aurora(MySQL8.0)における問題
今回は、レコード数の多いテーブルに対して ALTER でカラム追加をしていたのですが、Aurora MySQL のレプリケーションの影響か、リーダーインスタンスで一時的にテーブルが見つからないというエラーが出たので調べていました。
1Table 'hoge_table' doesn't exist
MySQL5.6、MySQL5.7、MySQL8.0 とバージョンアップするごとに、少しずつオンライン DDL の恩恵が大きくなってきていますが、もう少し安心して運用していけるといいな。
下記の記事に、私が遭遇した問題の再現検証が書かれていました。
まとめ
flyway_schema_history テーブルの以下のカラムについて確認してきました。
installed_on
execution_time
github actions から gradle で flyway 実行していたのですが、actions の実行ログに詳細な日時が記載されていなかったのですよね。
実行完了日時と実行時間がわかれば、開始日時も特定できそうです。