數據庫版本管理工具Flyway應用

時間 2019-11-18

原文原文鏈接

Flyway介紹

Flyway是一款開源的數據庫版本管理工具，它更傾向於規約優於配置的方式。Flyway能夠獨立於應用實現管理並跟蹤數據庫變動，支持數據庫版本自動升級，而且有一套默認的規約，不須要複雜的配置，Migrations能夠寫成SQL腳本，也能夠寫在Java代碼中，不只支持Command Line和Java API，還支持Build構建工具和Spring Boot等，同時在分佈式環境下可以安全可靠地升級數據庫，同時也支持失敗恢復等。mysql

Flyway用途

一般在項目開始時會針對數據庫進行全局設計，但在開發產品新特性過程當中，不免會遇到須要更新數據庫Schema的狀況，好比：添加新表，添加新字段和約束等，這種狀況在實際項目中也常常發生。那麼，當開發人員完成了對數據庫更的SQL腳本後，如何快速地在其餘開發者機器上同步？而且如何在測試服務器上快速同步？以及如何保證集成測試可以順利執行並經過呢？sql

到各測試服務器上手動執行SQL腳本費時費神費力的，幹嗎不自動化呢，固然，對於高級別和PROD環境，仍是須要DBA手動執行的。最後，寫一段自動化程序來自動執行更新，想法是很好的，那若是已經有了一些插件或庫能夠幫助你更好地實現這樣的功能，爲什麼很差好利用一下呢，固然，若是是爲了學習目的，重複造輪子是無可厚非的。其實，以上能夠經過Flyway工具來解決，Flyway能夠實現自動化的數據庫版本管理，而且可以記錄數據庫版本更新記錄。數據庫

Flyway命令

Flyway對數據庫進行版本管理主要由Metadata表和6種命令完成，Metadata主要用於記錄元數據，每種命令功能和解決的問題範圍不同，如下分別對metadata表和這些命令進行闡述，其中的示意圖都來自Flyway的官方文檔。安全

Metadata Table

Flyway中最核心的就是用於記錄全部版本演化和狀態的Metadata表，在Flyway首次啓動時會建立默認名爲flyway_schema_history的元數據表，其表結構爲(以MySQL爲例)：服務器

Migrate

Migrate是指把數據庫Schema遷移到最新版本，是Flyway工做流的核心功能，Flyway在Migrate時會檢查Metadata(元數據)表，若是不存在會建立Metadata表，Metadata表主要用於記錄版本變動歷史以及Checksum之類的。maven

Migrate時會掃描指定文件系統或Classpath下的Migrations(能夠理解爲數據庫的版本腳本)，而且會逐一比對Metadata表中的已存在的版本記錄，若是有未應用的Migrations，Flyway會獲取這些Migrations並按次序Apply到數據庫中，不然不須要作任何事情。另外，一般在應用程序啓動時應默認執行Migrate操做，從而避免程序和數據庫的不一致性。分佈式

Clean

清除掉對應數據庫Schema中的全部對象，包括表結構，視圖，存儲過程，函數以及全部的數據等都會被清除。Clean操做在開發和測試階段是很是有用的，它可以幫助快速有效地更新和從新生成數據庫表結構，但特別注意的是：不該在Production的數據庫上使用！函數

Info

Info用於打印全部Migrations的詳細和狀態信息，其實也是經過Metadata表和Migrations完成的，下圖很好地示意了Info打印出來的信息。Info可以幫助快速定位當前的數據庫版本，以及查看執行成功和失敗的Migrations。工具

Validate

Validate是指驗證已經Apply的Migrations是否有變動，Flyway是默認是開啓驗證的。Validate原理是對比Metadata表與本地Migrations的Checksum值，若是值相同則驗證經過，不然驗證失敗，從而能夠防止對已經Apply到數據庫的本地Migrations的無心修改。post

Baseline

Baseline針對已經存在Schema結構的數據庫的一種解決方案，即實如今非空數據庫中新建Metadata表，並把Migrations應用到該數據庫。Baseline能夠應用到特定的版本，這樣在已有表結構的數據庫中也能夠實現添加Metadata表，從而利用Flyway進行新Migrations的管理了。

Repair

Repair操做可以修復Metadata表，該操做在Metadata表出現錯誤時是很是有用的。Repair會修復Metadata表的錯誤，一般有兩種用途：

移除失敗的Migration記錄，該問題只是針對不支持DDL事務的數據庫。
從新調整已經應用的Migratons的Checksums值，好比：某個Migratinon已經被應用，但本地進行了修改，又指望從新應用並調整Checksum值，不過儘可能不要這樣操做，不然可能形成其它環境失敗。

支持的數據庫

目前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。

Flyway應用

Flyway能夠經過命令行和插件（如maven）的方式運行相應的命令，具體能夠參考https://flywaydb.org/getstarted/firststeps/commandline。

本文將會重點講解在Spring Boot中應用Flyway。

引入依賴

<!-- https://mvnrepository.com/artifact/org.flywaydb/flyway-core -->
<dependency>
	<groupId>org.flywaydb</groupId>
	<artifactId>flyway-core</artifactId>
	<version>5.0.7</version>
</dependency>

配置Flyway

flyway:
  locations: classpath:db/migration
  baseline-on-migrate: true
  url: jdbc:mysql://localhost:3306/test
  sql-migration-prefix: V
  sql-migration-suffix: .sql

咱們在配置文件中指定了如上的屬性。Flyway的配置屬性意義以下：

flyway.baseline-version：執行基線時用來標記已有Schema的版本（默認值：1）
flyway.enabled：開啓Flyway （默認爲true）
flyway.sql-migration-prefix：SQL遷移的文件名前綴
flyway.sql-migration-suffix ：SQL遷移的文件名後綴
flyway.baseline-on-migrate：在沒有元數據表的狀況下，針對非空Schema執行遷移時是否自動調用基線
flyway.location：遷移腳本的位置（默認爲db/migration）

正確建立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來保證可重複執行。

其中的文件名由如下部分組成，除了使用默認配置外，某些部分還可自定義規則。