flyway 實(shí)現(xiàn) java 自動升級 SQL 腳本
為什么要用Flyway
在日常開發(fā)中，我們經(jīng)常會遇到下面的問題：
自己寫的SQL忘了在所有環(huán)境執(zhí)行；
別人寫的SQL我們不能確定是否都在所有環(huán)境執(zhí)行過了；
有人修改了已經(jīng)執(zhí)行過的SQL，期望再次執(zhí)行；
需要新增環(huán)境做數(shù)據(jù)遷移；
每次發(fā)版需要手動控制先發(fā)DB版本，再發(fā)布應(yīng)用版本；
其它場景...
由于項(xiàng)目需求的變化，或者前期設(shè)計(jì)缺陷，導(dǎo)致在后期需要修改數(shù)據(jù)庫，這應(yīng)該是一個(gè)比較常見的事情，如果項(xiàng)目還沒上線，你可能把表刪除了重新創(chuàng)建，但是如果項(xiàng)目已經(jīng)上線了，就不能這樣簡單粗暴了，每次運(yùn)維部署項(xiàng)目，還得手動執(zhí)行一遍SQL文件。我們需要通過 SQL 腳本在已有數(shù)據(jù)表的基礎(chǔ)上進(jìn)行升級。
有了flyway，這些問題都能得到很好的解決。
使用了 Flyway 之后，如果再想進(jìn)行數(shù)據(jù)庫版本升級，就不用該以前的數(shù)據(jù)庫腳本了，直接創(chuàng)建新的數(shù)據(jù)庫腳本，項(xiàng)目在啟動時(shí)檢測了有新的更高版本的腳本，就會自動執(zhí)行，這樣，在和其他同事配合工作時(shí)，也會方便很多。因?yàn)檎Ｎ覀兌际菑?Git 上拉代碼下來，不拉數(shù)據(jù)庫腳本，這樣要是有人更新了數(shù)據(jù)庫，其他同事不一定能夠收到最新的通知，使用了 Flyway 就可以有效避免這個(gè)問題了。
所有的腳本，一旦執(zhí)行了，就會在 flyway_schema_history 表中有記錄，如果你不小心搞錯(cuò)了，可以手動從 flyway_schema_history 表中刪除記錄，然后修改 SQL 腳本后再重新啟動（生產(chǎn)環(huán)境不建議）。
Flyway是如何工作的
Flyway工作流程如下：
項(xiàng)目啟動，應(yīng)用程序完成數(shù)據(jù)庫連接池的建立后，F(xiàn)lyway自動運(yùn)行。
初次使用時(shí)，F(xiàn)lyway會創(chuàng)建一個(gè)flyway_schema_history表，用于記錄sql執(zhí)行記錄。
Flyway會掃描項(xiàng)目指定路徑下(默認(rèn)是classpath:db/migration)的所有sql腳本，與flyway_schema_history表腳本記錄進(jìn)行比對。如果數(shù)據(jù)庫記錄執(zhí)行過的腳本記錄，與項(xiàng)目中的sql腳本不一致，F(xiàn)lyway會報(bào)錯(cuò)并停止項(xiàng)目執(zhí)行。
如果校驗(yàn)通過，則根據(jù)表中的sql記錄最大版本號，忽略所有版本號不大于該版本的腳本。再按照版本號從小到大，逐個(gè)執(zhí)行其余腳本。
項(xiàng)目中使用Flyway
首先，在pom文件中引入flyway的核心依賴包：
1. 引入核心依賴包
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>5.2.4</version>
</dependency>
這里使用5.2.4版本。經(jīng)測試7.0.0版本與目前我們使用的springboot版本有沖突，會導(dǎo)致flyway不執(zhí)行。因此我們盡量不要使用高版本的flyway。
2. 配置文件
簡單配置一個(gè)屬性即可使用
# flyway 配置
spring:
flyway:
# 啟用或禁用 flyway
enabled: true
# flyway 的 clean 命令會刪除指定 schema 下的所有 table, 生產(chǎn)務(wù)必禁掉。這個(gè)默認(rèn)值是 false 理論上作為默認(rèn)配置是不科學(xué)的。
clean-disabled: true
# SQL 腳本的目錄,多個(gè)路徑使用逗號分隔 默認(rèn)值 classpath:db/migration
locations: classpath:db/migration
# metadata 版本控制信息表 默認(rèn) flyway_schema_history
table: flyway_schema_history
# 如果沒有 flyway_schema_history 這個(gè) metadata 表， 在執(zhí)行 flyway migrate 命令之前, 必須先執(zhí)行 flyway baseline 命令
# 設(shè)置為 true 后 flyway 將在需要 baseline 的時(shí)候, 自動執(zhí)行一次 baseline。
baseline-on-migrate: true
# 指定 baseline 的版本號,默認(rèn)值為 1, 低于該版本號的 SQL 文件, migrate 時(shí)會被忽略
baseline-version: 1
# 字符編碼 默認(rèn) UTF-8
encoding: UTF-8
# 是否允許不按順序遷移 開發(fā)建議 true 生產(chǎn)建議 false
out-of-order: false
# 需要 flyway 管控的 schema list,這里我們配置為flyway 缺省的話, 使用spring.datasource.url 配置的那個(gè) schema,
# 可以指定多個(gè)schema, 但僅會在第一個(gè)schema下建立 metadata 表, 也僅在第一個(gè)schema應(yīng)用migration sql 腳本.
# 但flyway Clean 命令會依次在這些schema下都執(zhí)行一遍. 所以 確保生產(chǎn) spring.flyway.clean-disabled 為 true
schemas: flyway
# 執(zhí)行遷移時(shí)是否自動調(diào)用驗(yàn)證 當(dāng)你的 版本不符合邏輯 比如 你先執(zhí)行了 DML 而沒有 對應(yīng)的DDL 會拋出異常
validate-on-migrate: trueflyway的properties配置清單(屬性未測試)：
# 對執(zhí)行遷移時(shí)基準(zhǔn)版本的描述.
flyway.baseline-description
#當(dāng)遷移時(shí)發(fā)現(xiàn)目標(biāo)schema非空，而且?guī)в袥]有元數(shù)據(jù)的表時(shí)，是否自動執(zhí)行基準(zhǔn)遷移，默認(rèn)false.
flyway.baseline-on-migrate =false
#開始執(zhí)行基準(zhǔn)遷移時(shí)對現(xiàn)有的schema的版本打標(biāo)簽，默認(rèn)值為1.
flyway.baseline-version=1
#檢查遷移腳本的位置是否存在，默認(rèn)false.
flyway.check-location=false
#當(dāng)發(fā)現(xiàn)校驗(yàn)錯(cuò)誤時(shí)是否自動調(diào)用clean，默認(rèn)false.
flyway.clean-on-validation-error=false
#是否開啟flywary，默認(rèn)true.
flyway.enabled=true
#設(shè)置遷移時(shí)的編碼，默認(rèn)UTF-8.
flyway.encoding
#當(dāng)讀取元數(shù)據(jù)表時(shí)是否忽略錯(cuò)誤的遷移，默認(rèn)false.
flyway.ignore-failed-future-migration
#當(dāng)初始化好連接時(shí)要執(zhí)行的SQL.
flyway.init-sqls
#遷移腳本的位置，默認(rèn)db/migration.
flyway.locations
#是否允許無序的遷移，默認(rèn)false.
flyway.out-of-order
#目標(biāo)數(shù)據(jù)庫的密碼.
flyway.password
#設(shè)置每個(gè)placeholder的前綴，默認(rèn)${.
flyway.placeholder-prefix
#是否要被替換，默認(rèn)true.
flyway.placeholder-replacementplaceholders
#設(shè)置每個(gè)placeholder的后綴，默認(rèn)}.
flyway.placeholder-suffix
#設(shè)置placeholder的value
flyway.placeholders.[placeholder name]
#設(shè)定需要flywary遷移的schema，大小寫敏感，默認(rèn)為連接默認(rèn)的schema.
flyway.schemas
#遷移文件的前綴，默認(rèn)為V.
flyway.sql-migration-prefix
#遷移腳本的文件名分隔符，默認(rèn)__
flyway.sql-migration-separator
#遷移腳本的后綴，默認(rèn)為.sql
flyway.sql-migration-suffix
#使用的元數(shù)據(jù)表名，默認(rèn)為schema_version
flyway.tableflyway
#遷移時(shí)使用的目標(biāo)版本，默認(rèn)為latest version
flyway.target
#遷移時(shí)使用的JDBC URL，如果沒有指定的話，將使用配置的主數(shù)據(jù)源
flyway.url
#遷移數(shù)據(jù)庫的用戶名
flyway.user
#遷移時(shí)是否校驗(yàn)，默認(rèn)為true
flyway.validate-on-migrateflyway的yml配置清單(已測試，沒問題，推薦使用yml格式的配置文件)
# flyway 配置
spring:
flyway:
# 啟用或禁用 flyway
enabled: true
# flyway 的 clean 命令會刪除指定 schema 下的所有 table, 生產(chǎn)務(wù)必禁掉。這個(gè)默認(rèn)值是 false 理論上作為默認(rèn)配置是不科學(xué)的。
clean-disabled: true
# SQL 腳本的目錄,多個(gè)路徑使用逗號分隔 默認(rèn)值 classpath:db/migration
locations: classpath:db/migration
# metadata 版本控制信息表 默認(rèn) flyway_schema_history
table: flyway_schema_history
# 如果沒有 flyway_schema_history 這個(gè) metadata 表， 在執(zhí)行 flyway migrate 命令之前, 必須先執(zhí)行 flyway baseline 命令
# 設(shè)置為 true 后 flyway 將在需要 baseline 的時(shí)候, 自動執(zhí)行一次 baseline。
baseline-on-migrate: true
# 指定 baseline 的版本號,默認(rèn)值為 1, 低于該版本號的 SQL 文件, migrate 時(shí)會被忽略
baseline-version: 1
# 字符編碼 默認(rèn) UTF-8
encoding: UTF-8
# 是否允許不按順序遷移 開發(fā)建議 true 生產(chǎn)建議 false
out-of-order: false
# 需要 flyway 管控的 schema list,這里我們配置為flyway 缺省的話, 使用spring.datasource.url 配置的那個(gè) schema,
# 可以指定多個(gè)schema, 但僅會在第一個(gè)schema下建立 metadata 表, 也僅在第一個(gè)schema應(yīng)用migration sql 腳本.
# 但flyway Clean 命令會依次在這些schema下都執(zhí)行一遍. 所以 確保生產(chǎn) spring.flyway.clean-disabled 為 true
schemas: flyway
# 執(zhí)行遷移時(shí)是否自動調(diào)用驗(yàn)證 當(dāng)你的 版本不符合邏輯 比如 你先執(zhí)行了 DML 而沒有 對應(yīng)的DDL 會拋出異常
validate-on-migrate: truespring.flyway.clean-disabled：這個(gè)屬性非常關(guān)鍵，它表示是否要清除已有庫下的表，如果執(zhí)行的腳本是 V1__xxx.sql，那么會先清除已有庫下的表，然后再執(zhí)行腳本，這在開發(fā)環(huán)境下還挺方便，但是在生產(chǎn)環(huán)境下就要命了，而且它默認(rèn)就是要清除，生產(chǎn)環(huán)境一定要自己配置設(shè)置為 true。
3. 創(chuàng)建db/migration
因?yàn)閒lyway默認(rèn)是讀取resources/db/migration下的文件夾，如果我們需要修改這個(gè)路徑，可以在配置文件中實(shí)現(xiàn)
4. 編寫sql文件
此處的SQL語句命名需要遵從一定的規(guī)范，否則運(yùn)行的時(shí)候flyway會報(bào)錯(cuò)。命名規(guī)則主要有兩種：
僅需要被執(zhí)行一次的SQL命名以大寫的"V"開頭，后面跟上"0~9"數(shù)字的組合,數(shù)字之間可以用“.”或者下劃線"_"分割開，然后再以兩個(gè)下劃線 __ 分割，其后跟文件名稱，最后以.sql結(jié)尾。比如，V20210707__create_user.sql、V20210707__add_user.sql。
可重復(fù)運(yùn)行的SQL，則以大寫的“R”開頭，后面再以兩個(gè)下劃線分割，其后跟文件名稱，最后以.sql結(jié)尾。。比如，R__truncate_user_dml.sql。
其中，V開頭的SQL執(zhí)行優(yōu)先級要比R開頭的SQL優(yōu)先級高。
V: 固定大寫
20210707.01：20210707是日期，后面用.01代表序號
因?yàn)閒lyway的執(zhí)行是有個(gè)順序的，比如你執(zhí)行了V2021__create_user，又執(zhí)行V2020_update_user。就會報(bào)錯(cuò)，原因就是2020<2021。所以我們要保證序號是依次增大。
Flyway 是如何比較兩個(gè) SQL 文件的先后順序呢？它采用 采用左對齊原則, 缺位用 0 代替 。舉幾個(gè)例子：
1.0.1.1 比 1.0.1 版本高。
1.0.10 比 1.0.9.4 版本高。
1.0.10 和 1.0.010 版本號一樣高, 每個(gè)版本號部分的前導(dǎo) 0 會被忽略。__:這個(gè)是兩個(gè) _
create_user是一個(gè)簡單的sql描述
.sql：以.sql結(jié)尾的文件后綴是約定
我們只要在數(shù)據(jù)庫中創(chuàng)建flyway這個(gè)數(shù)據(jù)庫，啟動項(xiàng)目，flyway就會執(zhí)行sql文件，創(chuàng)建user表，并且會自動生成一個(gè)flyway_schema_history表
從這段啟動日志中，我們可以看到 Flyway 的執(zhí)行信息，數(shù)據(jù)庫腳本的執(zhí)行執(zhí)行，同時(shí)這里還說了，F(xiàn)lyway 還給創(chuàng)建了一個(gè) flyway_schema_history 表，這個(gè)表用來記錄數(shù)據(jù)庫的更新歷史。
flyway_schema_history里面會去記錄sql文件的執(zhí)行記錄，每次啟動項(xiàng)目，都會去flyway_schema_history看sql是否執(zhí)行過，如果沒有執(zhí)行過，說明這個(gè)sql是新的sql，就會自動執(zhí)行，并且記錄到表里面。
有了這條記錄，下次再啟動項(xiàng)目，V20210707.01、V20210707.02、V20210708.01 這個(gè)三個(gè)腳本文件就不會執(zhí)行了，因?yàn)橄到y(tǒng)知道這個(gè)腳本已經(jīng)執(zhí)行過了，如果你還想讓這些腳本再執(zhí)行一遍，需要手動刪除 flyway_schema_history 表中的對應(yīng)記錄，那么項(xiàng)目啟動時(shí)，這個(gè)腳本就會被執(zhí)行了。
R開頭的文件和V開頭的文件略有不同，R開頭的文件只要發(fā)送修改，都會執(zhí)行一遍。V開頭的文件如果執(zhí)行過一般，在發(fā)送修改，就會報(bào)錯(cuò)。為了控制版本，我們盡量使用V開頭的文件，這樣我們也可以很清楚的看到每個(gè)版本中的sql文件。
常見問題
問題1
flyway遇到的問題Caused by: java.lang.ClassNotFoundException: org.flywaydb.core.api.callback.FlywayCallbac
原因：springboot版本和flyway版本不一致，一般是flyway版本過高。
解決辦法：將flyway的版本降到5.2.4就ok了
問題2
springboot 整合flyway 但是不生效，flyway不會自動執(zhí)行sql
原因：如上
原因2：項(xiàng)目中沒有配置數(shù)據(jù)庫，沒有引入sq依賴或者配置
解決辦法：如上
解決辦法2：引入sql依賴，在yml文件中配置sql信息
問題3
flyway出錯(cuò) FlywayException: Validate failed: Detected failed migration to version
原因：sql腳本和數(shù)據(jù)庫中有沖突，需要檢查sql腳本哪里錯(cuò)了。簡單的說就是V開頭的sql文件，已經(jīng)執(zhí)行過了，在 flyway_schema_history 表里面有這個(gè)數(shù)據(jù)，但是你又改動了sql文件，導(dǎo)致再次執(zhí)行的時(shí)候報(bào)錯(cuò)。
解決辦法：新建一個(gè)sql文件，不要修改原來以V開頭的文件或者在flyway_schema_history表中找到文件相關(guān)執(zhí)行記錄，刪掉重新執(zhí)行。
source: https://www.cnblogs.com/LoveBB/p/14983099.html
喜歡，在看