pom.xml添加maven依賴
<!-- https://mvnrepository.com/artifact/org.flywaydb/flyway-core -->
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>5.2.4</version>
</dependency>
application.yml文件添加Flyway配置
2.x的版本
spring.flyway.locations: classpath:/db/migration
spring.flyway.out-of-order: true
1.x版本
flyway.locations: classpath:db/migration
spring boot flyway 配置說明
flyway.baseline-description對執行遷移時基準版本的描述.
flyway.baseline-on-migrate當遷移時發現目標schema非空，而且帶有沒有元數據的表時，是否自動執行基準遷移，默認false.
flyway.baseline-version開始執行基準遷移時對現有的schema的版本打標籤，默認值爲1.
flyway.check-location檢查遷移腳本的位置是否存在，默認false.
flyway.clean-on-validation-error當發現校驗錯誤時是否自動調用clean，默認false.
flyway.enabled是否開啓flywary，默認true.
flyway.encoding設置遷移時的編碼，默認UTF-8.
flyway.ignore-failed-future-migration當讀取元數據表時是否忽略錯誤的遷移，默認false.
flyway.init-sqls當初始化好連接時要執行的SQL.
flyway.locations遷移腳本的位置，默認db/migration.
flyway.out-of-order是否允許無序的遷移，默認false.
flyway.password目標數據庫的密碼.
flyway.placeholder-prefix設置每個placeholder的前綴，默認${.
flyway.placeholder-replacementplaceholders是否要被替換，默認true.
flyway.placeholder-suffix設置每個placeholder的後綴，默認}.
flyway.placeholders.[placeholder name]設置placeholder的value
flyway.schemas設定需要flywary遷移的schema，大小寫敏感，默認爲連接默認的schema.
flyway.sql-migration-prefix遷移文件的前綴，默認爲V.
flyway.sql-migration-separator遷移腳本的文件名分隔符，默認__
flyway.sql-migration-suffix遷移腳本的後綴，默認爲.sql
flyway.tableflyway使用的元數據表名，默認爲schema_version
flyway.target遷移時使用的目標版本，默認爲latest version
flyway.url遷移時使用的JDBC URL，如果沒有指定的話，將使用配置的主數據源
flyway.user遷移數據庫的用戶名
flyway.validate-on-migrate遷移時是否校驗，默認爲true.
如何使用Flyway?
這裏將主要關注在Gradle和Spring Boot中集成並使用Flyway，數據庫通常會採用MySQL、PostgreSQL、H2或Hsql等。
正確創建Migrations
Migrations是指Flyway在更新數據庫時是使用的版本腳本，比如：一個基於Sql的Migration命名爲V1__init_tables.sql，內容即是創建所有表的sql語句，另外，Flyway也支持基於Java的Migration。Flyway加載Migrations的默認Locations爲classpath:db/migration，也可以指定filesystem:/project/folder，其加載是在Runtime自動遞歸地執行的。
除了需要指定Location外，Flyway對Migrations的掃描還必須遵從一定的命名模式，Migration主要分爲兩類：Versioned和Repeatable。
- Versioned migrations
一般常用的是Versioned類型，用於版本升級，每一個版本都有一個唯一的標識並且只能被應用一次，並且不能再修改已經加載過的Migrations，因爲Metadata表會記錄其Checksum值。其中的version標識版本號，由一個或多個數字構成，數字之間的分隔符可以採用點或下劃線，在運行時下劃線其實也是被替換成點了，每一部分的前導零會被自動忽略。 - Repeatable migrations
Repeatable是指可重複加載的Migrations，其每一次的更新會影響Checksum值，然後都會被重新加載，並不用於版本升級。對於管理不穩定的數據庫對象的更新時非常有用。Repeatable的Migrations總是在Versioned之後按順序執行，但開發者必須自己維護腳本並且確保可以重複執行，通常會在sql語句中使用CREATE OR REPLACE來保證可重複執行。
默認情況下基於Sql的Migration文件的命令規則如下圖所示：
其中的文件名由以下部分組成，除了使用默認配置外，某些部分還可自定義規則。
- prefix: 可配置，前綴標識，默認值
V表示Versioned，R表示Repeatable - version: 標識版本號，由一個或多個數字構成，數字之間的分隔符可用點
.或下劃線_ - separator: 可配置，用於分隔版本標識與描述信息，默認爲兩個下劃線
__ - description: 描述信息，文字之間可以用下劃線或空格分隔
- suffix: 可配置，後續標識，默認爲
.sql
在resource目錄下創建db/migration目錄添加sql腳本
報sql injection violation, comment not allow異常
創建flyway_schema_history表報錯,因爲flyway_schema_history創建表語句有註釋,導致durid防火牆攔截器.解決方法:去掉即可,或者手動創建flyway_schema_history表.
flyway 最佳實踐
SQL 的文件名
開發環境和生產環境的 migration SQL 不共用. 開發過程往往是多人協作開發, DB migration 也相對比較頻繁, 所以 SQL 腳本會很多. 而生產環境 DB migration 往往由 DBA 完成, 每次升級通常需要提交一個 SQL 腳本.
-
(1). 開發環境 SQL 文件建議採用時間戳作爲版本號.
開發環境 SQL 文件建議採用時間戳作爲版本號, 多人一起開發不會導致版本號爭用, 同時再加上生產環境的版本號, 這樣的話, 將來手工 merge 成生產環境 V1.2d migration 腳本也比較方便, SQL 文件示例:
V1.2.20180317.10.59__Unique_User_Names.sql
V1.2.20180317.14.59__Add_SomeTables.sql -
(2). 生產環境 SQL 文件, 應該是手動 merge 開發環境的 SQL 腳本, 版本號按照正常的版本, 比如
V2.1.5_001__Unique_User_Names.sql
migration 後的SQL 腳本不應該再被修改.
spring.flyway.out-of-order 取值 true /false
對於開發環境, 可能是多人協作開發, 很可能先 apply 了自己本地的最新 SQL 代碼, 然後發現其他同事早先時候提交的 SQL 代碼還沒有 apply, 所以 開發環境應該設置 spring.flyway.out-of-order=true, 這樣 flyway 將能加載漏掉的老版本 SQL 文件; 而生產環境應該設置 spring.flyway.out-of-order=false
多個系統公用要 DB schema
很多時候多個系統公用一個 DB schema , 這時候使用 spring.flyway.table 爲不同的系統設置不同的 metadata 表, 缺省爲 flyway_schema_history