web-dev-qa-db-ja.com

Flyway 3.0移行チェックサムの不一致

flyway Mavenプラグインを2.3から3.0にアップグレードした後、次のようになります。

[エラー]プロジェクトxxxでの目標org.flywaydb：flyway-maven-plugin：3.0：migrate（default-cli）の実行に失敗しました：org.flywaydb.core.api.FlywayException：Validate failed。適用された移行と利用可能な移行の違いが見つかりました：移行の移行チェックサムの不一致V003__data_feed_sources_locations.sql：DB = 942424992、Classpath = 1117634405-> [ヘルプ1]

他のプロジェクトでも同様のエラーが発生しました。

2.3にダウングレードすると、移行は正常に実行されます。これは、チェックサムを計算するための異なるプラットフォームエンコーディングと関係がありますか？

回避策、またはそれ以上の適切な解決策はありますか？

mavenflyway
44
bbcooper

Flyway 3.0は、validateOnMigrateのデフォルトをtrueに変更しました。

ただし、これは良いことです。フェイルファーストの精神で、エラーはより早く発見されます。

あなたの場合、いくつかのスクリプトは適用されてから変更されました。これはFlywayが報告しているものです。

次の2つのオプションがあります。

  • validateOnMigrateをfalseに設定してエラーを抑制します（2.3のデフォルトの動作）
  • flyway.repair（）を呼び出してチェックサムを再設定します
80
Axel Fontaine

Axel Fontaineの答えに追加するには：

私はmvn flyway：repairを使用できましたが、flyway.locations configプロパティを、db移行スクリプトを含むフォルダーでポイントする必要がありました。そうしないと、「メタデータテーブルxyz.schema_versionの修復は不要です。移行の失敗は検出されませんでした」というメッセージが表示されます。言及された他の人々のように。

mvn -Dflyway.locations=filesystem:<project dir>/src/main/resources/db/migrations flyway:repairを使用しましたが、メタデータテーブルでチェックサムが更新され、問題が修正されました。

16
tfendall

まず、チェックサムの変更を探します。これらの変更は、dbインスタンスに既に適用されている移行ファイルを更新する場合に発生します。

FlywayException：検証失敗：移行バージョン18.2.6の移行チェックサムの不一致

->データベースに適用：90181454

->ローカルで解決済み：717386176

repair（）メソッドは、ローカルチェックサム値でflyway_schema_historyテーブルを更新することにより、チェックサムの問題を修正します。

ただし、同じ移行ファイル内の更新されたステートメントは無視されます。 flyway_schema_historyテーブルにバージョンのエントリが既にあるため、同じファイルの新しい変更は無視されます。このシナリオでは、setValidateOnMigrate（）メソッドは効果がありません。インクリメンタルアプローチに従う必要があり、スキーマの変更は新しいファイルを通じて提供する必要があります。

3
Prashanth

この問題は、V1_2__books.sql ddlファイルを変更した直後に発生します。フライウェイに新しい変更を認識させるより良い方法があるはずです!!!

Mvn flyway：repairを実行しようとしましたが、機能しませんでした。application.propertiesファイル[datasource.flyway.url]のスキーマURLをbooks2に変更することになりました

以下のファイルも削除しました（booksは私の古いスキーマ名です）

~ @~:rm books.mv.db 
~ @~:rm -r books.trace.db 

datasource.flyway.url=jdbc:h2:file:~/books2
datasource.flyway.username=sa
datasource.flyway.password=
datasource.flyway.driver-class-name=org.h2.Driver

私はアプリケーションとビンゴを実行しました:)

2
Saif Masadeh

この問題を解決する最も簡単な方法は、スキーマテーブル内のチェックサムを文字通りフライウェイの期待値に更新することでした。移行ファイルが変更されておらず、データベースの現在の状態が必要なものであることを知っていました。また、ドキュメントを読んでFlyway.repair()または（潜在的にさらに混乱させる可能性のある他のメソッドをいじるのに時間を費やしたくありませんでした。簡単なSQLアップデートですぐに解決しました

1
aarbor

チェックサムを修復によって更新するために、追加したかっただけです。 Flywayは、すべての移行があるディレクトリにアクセスできる必要があります。それ以外の場合、フライウェイはビジネスとアウトプットについてだけです

「メタデータテーブルxyz.schema_versionでの失敗した移行の修復は必要ありません。失敗した移行は検出されませんでした。」

0
mfrancisy