Field | Type | Null | Key | Default |
---|---|---|---|---|
version_rank | int(11) | NO | MUL | NULL |
installed_rank | int(11) | NO | MUL | NULL |
version | varchar(50) | NO | PRI | NULL |
description | varchar(200) | NO | NULL | |
type | varchar(20) | NO | NULL | |
script | varchar(1000) | NO | NULL | |
checksum | int(11) | YES | NULL | |
installed_by | varchar(100) | NO | NULL | |
installed_on | timestamp | NO | CURRENT_TIMESTAMP | |
execution_time | int(11) | NO | NULL | |
success | tinyint(1) | NO | MUL | NULL |
Flyway官網上提供了一個很清晰的示例How Flyway works,可以參閱一下。
Migrate
Migrate是指把數據庫Schema遷移到最新版本,是Flyway工作流的核心功能,Flyway在Migrate時會檢查Metadata(元數據)表,如果不存在會創建Metadata表,Metadata表主要用于記錄版本變更歷史以及Checksum之類的。
Migrate時會掃描指定文件系統或Classpath下的Migrations(可以理解為數據庫的版本腳本),并且會逐一比對Metadata表中的已存在的版本記錄,如果有未應用的Migrations,Flyway會獲取這些Migrations并按次序Apply到數據庫中,否則不需要做任何事情。另外,通常在應用程序啟動時應默認執行Migrate操作,從而避免程序和數據庫的不一致性。
Clean
Clean相對比較容易理解,即清除掉對應數據庫Schema中的所有對象,包括表結構,視圖,存儲過程,函數以及所有的數據等都會被清除。
Clean操作在開發和測試階段是非常有用的,它能夠幫助快速有效地更新和重新生成數據庫表結構,但特別注意的是:不應在Production的數據庫上使用!
Info
Info用于打印所有Migrations的詳細和狀態信息,其實也是通過Metadata表和Migrations完成的,下圖很好地示意了Info打印出來的信息。
Info能夠幫助快速定位當前的數據庫版本,以及查看執行成功和失敗的Migrations。
Validate
Validate是指驗證已經Apply的Migrations是否有變更,Flyway是默認是開啟驗證的。
Validate原理是對比Metadata表與本地Migrations的Checksum值,如果值相同則驗證通過,否則驗證失敗,從而可以防止對已經Apply到數據庫的本地Migrations的無意修改。
Baseline
Baseline針對已經存在Schema結構的數據庫的一種解決方案,即實現在非空數據庫中新建Metadata表,并把Migrations應用到該數據庫。
Baseline可以應用到特定的版本,這樣在已有表結構的數據庫中也可以實現添加Metadata表,從而利用Flyway進行新Migrations的管理了。
Repair
Repair操作能夠修復Metadata表,該操作在Metadata表出現錯誤時是非常有用的。
Repair會修復Metadata表的錯誤,通常有兩種用途:
如何使用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文件的命令規則如下圖所示:
其中的文件名由以下部分組成,除了使用默認配置外,某些部分還可自定義規則。
另外,關于如何使用基于Java的Migrations,有興趣可以參考Java-based migrations。
支持的數據庫
目前Flyway支持的數據庫還是挺多的,包括:Oracle, SQL Server, SQL Azure, DB2, DB2 z/OS, MySQL(including Amazon RDS), MariaDB, Google Cloud SQL, PostgreSQL(including Amazon RDS and Heroku), Redshift, Vertica, H2, Hsql, Derby, SQLite, SAP HANA, solidDB, Sybase ASE and Phoenix。
目前來說,個人用得比較多的數據庫是PostgreSQL、MySQL、H2和Hsql,針對每種數據庫的flyway.url示例配置為:
另外,關于如何使用基于Java的Migrations,有興趣可以參考Java-based migrations。
支持的數據庫
目前Flyway支持的數據庫還是挺多的,包括:Oracle, SQL Server, SQL Azure, DB2, DB2 z/OS, MySQL(including Amazon RDS), MariaDB, Google Cloud SQL, PostgreSQL(including Amazon RDS and Heroku), Redshift, Vertica, H2, Hsql, Derby, SQLite, SAP HANA, solidDB, Sybase ASE and Phoenix。
目前來說,個人用得比較多的數據庫是PostgreSQL、MySQL、H2和Hsql,針對每種數據庫的flyway.url
示例配置為:
# PostgreSQL flyway.url = jdbc:postgresql://localhost:5432/postgres?currentSchema=myschema # MySQL flyway.url = jdbc:mysql://localhost:3306/testdb?serverTimezone=UTCuseSSL=true # H2 flyway.url = jdbc:h2:./.tmp/testdb # Hsql flyway.url = jdbc:hsqldb:hsql//localhost:1476/testdb
Flyway命令行
Flyway的命令行工具支持直接在命令行中運行Migrate
,Clean
,Info
,Validate
,Baseline
和Repair
6種命令,不需要借助其他Build工具,不需要應用程序運行在JVM中,只需要單純的命令行即可,但需要根據不同的操作系統下載并安裝該命令行工具。Flyway會依次搜索以下配置文件,越靠后的配置會覆蓋靠前的配置:
一個典型Flyway項目示例目錄結構如下:
更多關于Flyway命令行使用可以參考Flyway Command-line。
在Gradle中的應用
首先需要在Gradle中引入Flyway插件,通常有兩種方式:
方式一:采用buildscript依賴方式。
buildscript { repositories { mavenCentral() } dependencies { classpath("org.flywaydb:flyway-gradle-plugin:4.0.3") } } apply plugin: 'org.flywaydb.flyway'
方式二(推薦):采用DSL方式引用Plugins。
plugins { id "org.flywaydb.flyway" version "4.0.3" }
而在Gradle中配置Flyway Properties有兩種方式:
方式一:在build.gradle
中配置Flyway Properties。
flyway { url = jdbc:h2:./.tmp/testdb user = sa password = } # 或者寫成: project.ext['flyway.url'] = 'jdbc:h2:./.tmp/testdb' project.ext['flyway.user'] = 'sa' project.ext['flyway.password'] = ''
方式二:在gradle.properties
中配置Flyway Properties。
flyway.url = jdbc:h2:./.tmp/testdb flyway.user = sa flyway.password =
如果期望在運行Gradle Clean/Build Tasks時自動執行Flyway的某些任務,可以設置dependsOn
,若不期望隱式執行Flyway任務,可以不配置。
clean.dependsOn flywayRepair # To repair the Flyway metadata table build.dependsOn flywayMigrate # To migrate the schema to the latest version
另外,其它Tasks:flywayInfo
,flywayValidate
,flywayBaseline
分別對應到Flyway的命令。在使用Spring Boot時,運行./gradlew bootRun
會自動檢查并加載最新的db.migration腳本。
特別注意:在Production環境中不應執行./gradlew flywayClean
,除非你知道自己的行為和目的,因為該命令會清除所有的數據庫對象,相當危險。
更多關于Flyway在Gradle中的使用請參閱Flyway Gradle Plugin。
與Spring Boot集成
在Spring Boot中,如果加入Flyway的依賴,則會自動引用Flyway并使用默認值,但可以修改并配置FlywayProperties。
flyway.baseline-description= # The description to tag an existing schema with when executing baseline. flyway.baseline-version=1 # Version to start migration. flyway.baseline-on-migrate=false # Whether to execute migration against a non-empty schema with no metadata table flyway.check-location=false # Check that migration scripts location exists. flyway.clean-on-validation-error=false # will clean all objects. Warning! Do NOT enable in production! flyway.enabled=true # Enable flyway. flyway.encoding=UTF-8 # The encoding of migrations. flyway.ignore-failed-future-migration=true # Ignore future migrations when reading the metadata table. flyway.init-sqls= # SQL statements to execute to initialize a connection immediately after obtaining it. flyway.locations=classpath:db/migration # locations of migrations scripts. flyway.out-of-order=false # Allows migrations to be run "out of order". flyway.placeholder-prefix= # The prefix of every placeholder. flyway.placeholder-replacement=true # Whether placeholders should be replaced. flyway.placeholder-suffix=} # The suffix of every placeholder. flyway.placeholders.*= # Placeholders to replace in Sql migrations. flyway.schemas= # Default schema of the connection and updating flyway.sql-migration-prefix=V # The file name prefix for Sql migrations flyway.sql-migration-separator=__ # The file name separator for Sql migrations flyway.sql-migration-suffix=.sql # The file name suffix for Sql migrations flyway.table=schema_version # The name of Flyway's metadata table. flyway.url= # JDBC url of the database to migrate. If not set, the primary configured data source is used. flyway.user= # Login user of the database to migrate. If not set, use spring.datasource.username value. flyway.password= # JDBC password if you want Flyway to create its own DataSource. flyway.validate-on-migrate=true # Validate sql migration CRC32 checksum in classpath.
若使用Gradle,通常在build.gradle
引入org.flywaydb:flyway-core:4.0.3
依賴后即可使用。可能會有以下幾種需求:
spring.jpa.hibernate.ddl-auto
都設置為validate
,Schema不需要Hibernate自動生成,并期望使用Flyway,而在線上環境會使用真實數據庫,并不期望使用Flyway,如何實現呢?common.properties
中配置flyway.enabled=false
,然后在local或dev的配置中啟用Flyway即可。通常推薦使用此模式,畢竟可以對不同的環境進行控制,另外本地Run不會依賴真實數據庫,又能保證數據庫Schema是按腳本創建的。解決方案:設置bootRun.dependsOn
動態添加Flyway的依賴即可:
addFlywayDenpendency { doLast { dependencies { compile('org.flywaydb:flyway-core:4.0.3') } } } bootRun.dependsOn=addFlywayDenpendency
若項目有多個團隊同時開發不同的功能,需要新建多個分支,并且都會涉及到數據庫Schema更改,當后期Merge時,Migration的版本如何控制并且不會產生數據庫更改的沖突呢?
解決方案:如果兩個分支的數據庫更改有沖突,要么最初數據庫設計不合理,要么目前數據庫更改不合理,所以需要團隊進行全局考慮和協調。而針對數據庫在同一段時間有修改,但不會造成沖突的情況,通常實際項目中主要存在這樣的情況,那可以設置flyway.out-of-order=true
,這樣允許當v1和v3已經被應用后,v2出現時同樣也可以被應用。其實在本地使用內存數據庫不會存在該問題,因為數據庫所有對象會自動清除掉,而在local或dev中使用真實數據庫時可遇到這樣的問題,因此需要注意一下了。
另外,值得一提的是Flyway的參數ignore-failed-future-migration
默認為true
,使用情形為:當Rollback數據庫更改到舊版本,而metadata表中已存在了新版本時,Flyway會忽略此錯誤,只會顯示警告信息。
結束語
總得來說,Flyway可以有效改善數據庫版本管理方式,如果項目中還未使用,不防嘗試一下。如果有興趣,也可以關注MyBatis Migration,功能支持沒有Flyway多,屬于更輕量級的數據庫版本管理工具。如果在使用過程中遇到了問題或坑,歡迎留言一起交流討論。
References
Flyway Documentation
Gradle Plugin: Flyway
Spring Common application properties
Execute Flyway database migrations on startup
到此這篇關于快速掌握和使用Flyway的詳細教程的文章就介紹到這了,更多相關使用Flyway的技巧內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家!
標簽:鄂爾多斯 莆田 哈爾濱 丹東 遵義 錫林郭勒盟 襄陽 雙鴨山
巨人網絡通訊聲明:本文標題《快速掌握和使用Flyway的詳細教程》,本文關鍵詞 快速,掌握,和,使用,Flyway,;如發現本文內容存在版權問題,煩請提供相關信息告之我們,我們將及時溝通與處理。本站內容系統采集于網絡,涉及言論、版權與本站無關。