flyway java SQLスクリプトの自動アップグレードを実現する問題と解決方法

10593 ワード
java 級が上がる SQLスクリプト
なぜFlywayを使いますか？
日常開発において、私たちはよく次のような問題に遭遇します。
  • 自分で書いたSQLは全ての環境で実行することを忘れました。
  • 他の人が書いたSQLは全ての環境で実行されたかどうかを確認できません。
  • 実行済みのSQLを修正した人がいます。再度実行したいです。
  • データの移動を行うために環境を追加する必要があります。
  • 毎回バージョンを出す時、手動でDBバージョンを制御してからアプリケーションバージョンをリリースします。
    • 他のシーンは…
    プロジェクトの需要の変化、或いは前期の設計の欠陥によって、後期にデータベースを修正する必要があります。これは比較的によくあることです。プロジェクトがまだオンラインになっていないなら、表を削除して新しく作成することができます。しかし、プロジェクトが既にオンラインになっているなら、こんなに簡単で乱暴にはできません。毎回、プロジェクトを運営して、また手動でSQLファイルを実行しなければなりません。私たちはSQLスクリプトを通じて既存のデータテーブルをアップグレードする必要があります。
    flywayがあれば、これらの問題はよく解決されます。
    Flywayを使用した後、データベースバージョンのアップグレードを行いたいなら、元のデータベーススクリプトを使わずに、直接新しいデータベーススクリプトを作成します。プロジェクトは起動時に新しいより高いバージョンのスクリプトを検出したら、自動的に実行されます。他の同僚と仕事をする時にも便利です。通常はGitからコードを引いていますので、データベースのスクリプトを引っ張らないと、他の同僚がデータベースを更新したら、最新の通知を受けることができるとは限りません。Flywayを使ったら、この問題を効果的に避けることができます。
    すべてのシナリオは、一度実行するとflywayになります。schemahistory表に記録があります。もし間違えたら、手動でflyway_からできます。schemahistory表から記録を削除し、SQLスクリプトを修正して再起動する（生産環境は推奨されない）。
    Flywayはどのように働いていますか？
    Flyway仕事の流れは以下の通りです。
    1、プロジェクトが起動し、アプリケーションがデータベース接続池の建設を完了した後、Flywayは自動的に実行する。
    2、初めて使用する場合、Flywayはsql実行記録を記録するためにflyway_schema_history表を作成します。
    3、Flywayはプロジェクト指定のパス（デフォルトはclasspath:db/migration）のすべてのSqlスクリプトをスキャンして、flyway_schema_historyテーブルのスクリプト記録と比較します。データベース記録が実行されたスクリプト記録がプロジェクトのsqlスクリプトと一致しない場合、Flywayはエラーを報告してプロジェクトの実行を停止します。
    4、チェックが通れば、テーブルのsqlに従って最大バージョン番号を記録し、すべてのバージョン番号がこのバージョンのスクリプトより大きくないことを無視します。バージョン番号によって小さい時から大きい時まで、残りのスクリプトを一つずつ実行します。
    プロジェクトではFlywayを使用します。
    まず、pomファイルにflywayのコア依存パッケージを導入します。
    1、コア依存パッケージを導入する：
    
 <dependency>
             <groupId>org.flywaydb</groupId>
             <artifactId>flyway-core</artifactId>
             <version>5.2.4</version>
</dependency>

    ここでは5.2.4バージョンを使用します。テスト7.0.0バージョンは現在使っているspringbootバージョンと衝突しています。flywayが実行されないことになります。だから、なるべく高いバージョンのflywayを使わないようにします。
    2、プロファイル：
    属性を簡単に設定すれば使用できます。
    
# flyway   
 spring:
   flyway:
     #       flyway
     enabled: true
     # flyway   clean         schema      table,       。       false               。
     clean-disabled: true
     # SQL      ,               classpath:db/migration
     locations: classpath:db/migration
     #  metadata            flyway_schema_history
     table: flyway_schema_history
     #      flyway_schema_history    metadata  ，     flyway migrate     ,       flyway baseline   
     #     true   flyway      baseline    ,        baseline。
     baseline-on-migrate: true
     #    baseline     ,     1,         SQL   , migrate      
     baseline-version: 1
     #         UTF-8
     encoding: UTF-8
     #                 true       false
     out-of-order: false
     #    flyway     schema list,       flyway      ,   spring.datasource.url       schema,
     #       schema,        schema    metadata  ,       schema  migration sql   .
     #  flyway Clean         schema      .         spring.flyway.clean-disabled   true
     schemas: flyway
     #                                      DML        DDL      
     validate-on-migrate: true
    flywayのproperties配置リスト（属性未テスト）：
    
#              .
 flyway.baseline-description
 #        schema  ，            ，          ，  false.
 flyway.baseline-on-migrate =false
 #             schema      ，    1.
 flyway.baseline-version=1
 #             ，  false.
 flyway.check-location=false
 #              clean，  false.
 flyway.clean-on-validation-error=false
 #    flywary，  true.
 flyway.enabled=true
 #        ，  UTF-8.
 flyway.encoding
 #                 ，  false.
 flyway.ignore-failed-future-migration
 #            SQL.
 flyway.init-sqls
 #       ，  db/migration.
 flyway.locations
 #         ，  false.
 flyway.out-of-order
 #        .
 flyway.password
 #    placeholder   ，  ${.
 flyway.placeholder-prefix
 #      ，  true.
 flyway.placeholder-replacementplaceholders
 #    placeholder   ，  }.
 flyway.placeholder-suffix
 #  placeholder value
 flyway.placeholders.[placeholder name]
 #    flywary   schema，     ，        schema.
 flyway.schemas
 #       ，   V.
 flyway.sql-migration-prefix
 #           ，  __
 flyway.sql-migration-separator
 #       ，   .sql
 flyway.sql-migration-suffix
 #        ，   schema_version
 flyway.tableflyway
 #          ，   latest version
 flyway.target
 #      JDBC URL，        ，          
 flyway.url
 #         
 flyway.user
 #       ，   true
 flyway.validate-on-migrate
    flywayのyml配置リスト（テストしました。大丈夫です。yml形式の配置ファイルを推奨します。）
    
# flyway   
 spring:
   flyway:
     #       flyway
     enabled: true
     # flyway   clean         schema      table,       。       false               。
     clean-disabled: true
     # SQL      ,               classpath:db/migration
     locations: classpath:db/migration
     #  metadata            flyway_schema_history
     table: flyway_schema_history
     #      flyway_schema_history    metadata  ，     flyway migrate     ,       flyway baseline   
     #     true   flyway      baseline    ,        baseline。
     baseline-on-migrate: true
     #    baseline     ,     1,         SQL   , migrate      
     baseline-version: 1
     #         UTF-8
     encoding: UTF-8
     #                 true       false
     out-of-order: false
     #    flyway     schema list,       flyway      ,   spring.datasource.url       schema,
     #       schema,        schema    metadata  ,       schema  migration sql   .
     #  flyway Clean         schema      .         spring.flyway.clean-disabled   true
     schemas: flyway
     #                                      DML        DDL      
     validate-on-migrate: true
    spring.flyway.clean-disable：この属性は非常に重要です。既存のライブラリのテーブルをクリアするかどうかを表しています。もし実行されるシナリオがV 1_uです。xxx.sqlでは、既存のライブラリのテーブルをクリアしてからスクリプトを実行します。これは開発環境の下ではとても便利ですが、生産環境の下では命がかかります。そして、デフォルトではクリアします。生産環境は必ず自分で設定してtrueに設定してください。
    3、db/migrationを作成する
    flywayはデフォルトではresource/db/migrationの下のフォルダを読み込むので、このパスを修正する必要があれば、設定ファイルで実現できます。

    4、sqlファイルを作成する
    ここのSQL文の名前は一定の規範に従う必要があります。さもなければ運行時にflywayはエラーを報告します。命名規則は主に二つあります。
  • は、一回実行されるSQLだけを大文字の「V」と命名し、後に「0~9」の数字の組み合わせを追えば、数字の間に「.」または下線「_」を用いることができます。分割して二つの下線を引いてください。分割し、その後はファイル名と、最後は.sqlで終了します。例えば、V20210707__create_user.sql、V20210707__add_user.sql。
  • が繰り返し実行できるSQLは、大文字の「R」で始まり、後に2つの下線で分割され、その後はファイル名となり、最後にsqlで終わる。例えば、R__truncate_user_dml.sql。
    • ここで、V先頭のSQLは、R先頭のSQLより優先度が高い。
    V:固定大文字
    2010707.01:202910707は日付で、後は.01は番号を表します。
    flywayの実行には順番がありますので、例えば、V 2021_u 0026 quot;を実行しました。クリアードアメリカ、またV 2020_を実行します。udate_user2020<2021>がエラーとなります。ですから、順番が順次増えることを保証します。
    Flywayはどのように二つのSQLファイルの先着順を比較しますか？左揃えの原則を採用しています。空白は0で代用します。いくつかの例を挙げます
     1.0.1.1は1.0.1バージョンより高いです。
     ​
     1.0.10は1.0.94より高いです。
     ​
     1.0.10と1.0.010バージョン番号は同じ高さで、各バージョン番号部分のプリアンブル0は無視されます。
    ウ_:これは二つの_です
    クリアードuserは簡単なsql記述です。
    .sql:以.sql结末的ファイルサフィックスは约束です。





    私達はデータベースの中でflywayというデータベースを作りさえすれば、プロジェクトを起動します。flywayはsqlファイルを実行して、user表を作成します。そして自動的にflywayを生成します。schemahistory表

    この起動ログからFlywayの実行情報、データベーススクリプトの実行を見ることができます。また、Flywayはflywayを作成しました。schemahistory表、この表はデータベースの更新履歴を記録するものです。

    flywayschemahistoryではsqlファイルの実行記録を記録しています。プロジェクトを起動するたびにflywayに行きます。schemahistoryはsqlが実行したかどうかを見て、もし実行したことがないならば、このsqlは新しいsqlだと説明して、自動的に実行して、そして表の中に記録します。

    この記録があったら、次回からプロジェクトを起動します。V 2010707.01、V 2010707.02、V 2010708.01という三つのスクリプトファイルは実行されません。システムはこのスクリプトがすでに実行されたことを知っていますので、これらのスクリプトをもう一度実行したいなら、手動でflyway_を削除してください。schemahistoryテーブルの対応記録は、プロジェクトが起動すると、このスクリプトが実行されます。
    R先頭のファイルとV先頭のファイルは少し違っています。R先頭のファイルは修正を送信するだけで、一回実行します。V先頭のファイルが一般的に実行された場合、修正を送信しているとエラーが発生します。バージョンを制御するために、できるだけVの先頭のファイルを使って、各バージョンのsqlファイルをよく見ることができます。
    よくある問題
    問題1
    flywayが遭遇した問題Caused by：java.lang.class NotFoundException：org.flywaydb.co.ap.call back.FlywayCallbac
    理由：springbootバージョンとflywayバージョンは違っています。普通はflywayバージョンが高すぎます。
    解決方法：flywayのバージョンを5.2.4に下げたらいいです。
    問題2
    springbootはflywayを整合しますが、有効ではありません。flywayは自動的にsqlを実行しません。
    理由：上記のとおりです
    理由2：プロジェクトにはデータベースが設定されておらず、sq依存または配置が導入されていません。
    解決方法：以上のとおりです。
    解決方法2：sql依存を導入し、ymlファイルにsql情報を配置する。
    問題3
    flywayエラーFlywayException:Validate failed:Detected failed migration to version
    原因：sqlシナリオとデータベースの中で衝突があって、sql脚本はどこが間違っていますか？簡単に言えば、Vで始まるsqlファイルはもう実行しました。flyway_schemahistory表にこのデータがありますが、sqlファイルを変更して再実行した時にエラーが発生しました。
    解決方法：sqlファイルを新規作成します。元のVで始まるファイルを修正しないでください。またはflywayで。schemahistoryテーブルでファイル関連の実行記録を見つけ、削除して再実行します。
    天下には有料のバスがありません。出典：https://www.cnblogs.com/LoveBB/本著作権は著者とブログパークに共有され、転載を歓迎するが、作者の同意なしに文章のページに原文のリンクを与えなければならない。そうでなければ法律責任を追及する権利を保留する。
    以上でflywayのJava自動アップグレードSQLスクリプトの問題と解決方法についての文章を紹介しました。java自動アップグレードSQLスクリプトの内容については、以前の文章を検索したり、下記の関連記事を見たりしてください。これからもよろしくお願いします。