私たちは、MySQL 5.6（トランザクションDDLをサポートしていない）に対してJava APIを介してFlyway 4を使用します。私たちは、マイグレーションが失敗するまれなケース、時には論理エラー、および時にはデータベースを酷使して物事が正しい状態にないために実行します。schema_versionから行を削除するのは正しいことですか？
この場合、schema_versionの行を削除して、移行またはデータベースの修正プログラムのいずれかを使用して移行を再実行する必要がありますか？移行前に修復を実行して失敗した移行を修正した後、新しい移行を追加します。
も参照してください：Should I be worried about creating idempotent migrations while using Flyway?
私は過去数年間のためのフライウェイ3を使用してきたし、ちょうど最近4にアップグレードしました。これまでのところ、30種類ほどの異なるプロジェクトを成功裏に管理し、配信パイプラインにうまく収まりました。
2年の歴史の中で私たちが除去したい開発者のマシンから2年間の移行を経験しました。そのような場合、schema_versionから行を削除するのが通常の答えです。それはrepairよりも速く、処理の負荷が少なく、われわれの状況ではリスクが低くなります。つまり、これまで開発/テスト環境までしか作れませんでした。そのため、常にマイグレーションが行われ、失敗した/不要なものはありませんでした。
私たちは、失敗した移行をビルド時間の問題にすることを確実に目指しています。そのため、移行バージョンが検証され、移行自体が実行され、コンポーネントはそのコンポーネントのビルドの一部として移行されたデータベースに対して実行されます。このような膨大な数の移行管理プロジェクトを処理する際に、これがめったに問題にならないことが大きな原因となっていると思います。
フライウェイの文脈で読んだところを思い出すことはできませんが、それはThe price we pay for this kind of automation is disciplineの行に沿ったものでした。「データベースを手作業で手に取った人のように聞こえるのは間違いなく赤です私のための旗。結論として
...私がキーだと思う障害の機会を最小化
。しかし、障害が発生した場合、許容レベルのリスクを満たすように戦略を定義することが、あなたができる最善の方法です。repairと削除することは、両方とも欠点があります。schema_version
修理の欠点と考えられるものを明確にすることはできますか？ –
@JohnAment確かに。適用されているチェックサムでは、「修復」は無差別です。使用可能なものに再調整されます。これにより、あなたが思っている以上に（例えば、別の移行が変更された場合など）、あなたが「修復」している状況が生まれる可能性があります。基本的に、あなたは 'validate'があなたに与えるすべての保護をオプトアウトしています。 – markdsievers