資料庫遷移神器——Flyway

橘子發表於2020-08-13
資料庫

不知道你有沒有遇到過這種場景，一套程式碼部署在不同的環境中，隨著時間的過去，各個環境程式碼有版本差異，程式碼層面可以通過不同的版本來控制，但是資料庫層面經常容易忘記更新！

前言

比如剛開始環境 A 和環境 B 的程式碼版本是一樣的，但是隨著版本的迭代，環境 A 的系統一直持續迭代，但是環境 B 的系統由於種種原因沒有升級，一直保持在最初的版本。如果某個時候需要對環境 B 的系統進行升級的話，你會發現，中間已經過了好多個版本，各個版本的差距很大，資料庫結構有調整，不能直接打包釋出，需要把之前所有對環境 A 調整的 SQL 都在環境 B 中執行一遍才行。

這個時候如果 SQL 版本做的好的問題不大，依次執行就行了，但是如果中間有人員離職或者記錄缺失，那隻能通過對比資料庫結構來進行解決了。

資料遷移

前面我們的提到的場景專業的名詞叫資料遷移，那為什麼會出現資料遷移的場景呢？我從官網截了一張圖大家可以看下，雖然說可能跟我實際開發不是一樣，但是也差不多類似會出現這種場景，存在多個環境。可以看到雖然我們的程式碼可以通過版本迭代來控制，但是我們的資料庫卻不行，很多時候連指令碼是否執行過都會忘記，這種事情光靠人記是很難的。

資料庫遷移神器——Flyway

Flyway

Flyway 就是用來解決像這樣的資料庫遷移的工具，接入了 Flyway 過後，在資料庫中會生成一張預設名為flyway_schema_history 的資料表，用來追蹤資料庫的變化。程式啟動的時候 Flyway 都會在檔案系統或者 classpath 路徑下面尋找遷移指令碼。每個遷移腳步都有相應的命名規則，Flyway 會根據檔案的版本號進行遷移，每次遷移過後都會在flyway_schema_history 表中插入一條類似如下的記錄，記錄版本已經對應的指令碼檔案和校驗碼等資訊：

資料庫遷移神器——Flyway

每次啟動的時候只會執行最高版本的指令碼，而且如果版本沒變，指令碼變了是啟動不了的。

資料庫遷移神器——Flyway

Flyway 的遷移型別

版本遷移

最常見的遷移就是就是版本化遷移，每次遷移都會對應的遷移版本，遷移的版本必須全域性唯一，版本遷移最大的特點就是依次只被執行依次。

撤銷遷移

每個撤銷遷移都對應的一個版本遷移，也就是說撤銷遷移是針對版本遷移所存在的，每一個撤銷遷移與版本遷移都是一一對應的，而且對應的版本號必須一致。

可重複遷移

可重複遷移有描述和校驗碼，但是沒有版本號，程式在每次啟動的時候，如果發現指令碼檔案有變化就會執行。

基於 SQL 的遷移

上面提到的幾種型別都是基於 SQL 檔案來執行的，只不過每種型別的命名格式不一樣，下圖是從官網上截下來的，大家看下每種型別的檔案應該按照如下的格式去命令，其中的 Separator 是兩個下劃線。

資料庫遷移神器——Flyway

主要分為下面幾個部分：

prefix：字首，不同的型別採用不同的字首，版本遷移使用 V，撤銷遷移使用 U，可重複遷移使用 R，當然這些都是可配置的；

Version：版本號，可以使用點符號或者單下劃線連結；

Separator：分隔符，兩個下劃線，也是可以配置的；

Description：版本描述可以用下劃線和空格分隔；

Suffix：字尾，一般都是 .sql

SpringBoot 專案接入 Flyway

SpringBoot 專案接入 Flyway 非常簡單，主要分為如下幾步即可，我們依次來看一下。

加入依賴

 <!-- flyway -->
 <dependency>
     <groupId>org.flywaydb</groupId>
     <artifactId>flyway-core</artifactId>
 </dependency>

 

在專案 pom.xml 檔案中加入上面的依賴即可。

增加配置

# 啟用 flyway
spring.flyway.enabled=true
# 禁止清理資料表
spring.flyway.clean-disabled=true
# 是否已經有資料庫
spring.flyway.baseline-on-migrate=true
# 基礎版本號，依次遞增
spring.flyway.baseline-version=0
# 遷移指令碼的存放的位置
spring.flyway.locations=classpath:db/migration

 

這裡因為很多情況下我們並不是一個新專案就開始使用 Flyway，而是專案在迭代中才引入的，所以上面的配置spring.flyway.clean-disabled=true 一定要禁用。上面幾個配置由於已經繼承到 SpringBoot 中了所以配置起來十分簡單。

遷移指令碼檔案

指令碼的命名規則按照上面說的，我們這邊採用版本遷移。我們建立一個版本的 SQL 檔案放到對應的類路徑資料夾裡面，檔名叫V1.2__create_test_table.sql，檔案內容如下，然後我們啟動專案。

CREATE TABLE `test_table`  (
  `id` int(11) NULL COMMENT 'ID',
  `name` varchar(255) NULL COMMENT 'Name'
);

 

啟動過程中我們看到如下日誌，顯示了當前的版本，以及遷移的版本。
資料庫遷移神器——Flyway

我們再檢視資料庫，首先 test_table 已經建立成功了

資料庫遷移神器——Flyway

另外我們在檢視flyway_schema_history 表，會發現已經多了一條版本資料，至此我們介入 Flyway 已經成功了。

資料庫遷移神器——Flyway

總結

今天給大家介紹了一個資料庫版本遷移的工具，這麼好的工具大家趕緊用起來吧，這樣在以後的版本迭代的過程中再也不會忘記執行SQL 了。這篇文章先跟大家介紹 Flyway 的使用，下篇文章我們再分享它的實現原理。

不知道你有沒有遇到過這種場景，一套程式碼部署在不同的環境中，隨著時間的過去，各個環境程式碼有版本差異，程式碼層面可以通過不同的版本來控制，但是資料庫層面經常容易忘記更新！

前言

比如剛開始環境 A 和環境 B 的程式碼版本是一樣的，但是隨著版本的迭代，環境 A 的系統一直持續迭代，但是環境 B 的系統由於種種原因沒有升級，一直保持在最初的版本。如果某個時候需要對環境 B 的系統進行升級的話，你會發現，中間已經過了好多個版本，各個版本的差距很大，資料庫結構有調整，不能直接打包釋出，需要把之前所有對環境 A 調整的 SQL 都在環境 B 中執行一遍才行。

這個時候如果 SQL 版本做的好的問題不大，依次執行就行了，但是如果中間有人員離職或者記錄缺失，那隻能通過對比資料庫結構來進行解決了。

資料遷移

前面我們的提到的場景專業的名詞叫資料遷移，那為什麼會出現資料遷移的場景呢？我從官網截了一張圖大家可以看下，雖然說可能跟我實際開發不是一樣，但是也差不多類似會出現這種場景，存在多個環境。可以看到雖然我們的程式碼可以通過版本迭代來控制，但是我們的資料庫卻不行，很多時候連指令碼是否執行過都會忘記，這種事情光靠人記是很難的。

資料庫遷移神器——Flyway

Flyway

Flyway 就是用來解決像這樣的資料庫遷移的工具，接入了 Flyway 過後，在資料庫中會生成一張預設名為flyway_schema_history 的資料表，用來追蹤資料庫的變化。程式啟動的時候 Flyway 都會在檔案系統或者 classpath 路徑下面尋找遷移指令碼。每個遷移腳步都有相應的命名規則，Flyway 會根據檔案的版本號進行遷移，每次遷移過後都會在flyway_schema_history 表中插入一條類似如下的記錄，記錄版本已經對應的指令碼檔案和校驗碼等資訊：

資料庫遷移神器——Flyway

每次啟動的時候只會執行最高版本的指令碼，而且如果版本沒變，指令碼變了是啟動不了的。

資料庫遷移神器——Flyway

Flyway 的遷移型別

版本遷移

最常見的遷移就是就是版本化遷移，每次遷移都會對應的遷移版本，遷移的版本必須全域性唯一，版本遷移最大的特點就是依次只被執行依次。

撤銷遷移

每個撤銷遷移都對應的一個版本遷移，也就是說撤銷遷移是針對版本遷移所存在的，每一個撤銷遷移與版本遷移都是一一對應的，而且對應的版本號必須一致。

可重複遷移

可重複遷移有描述和校驗碼，但是沒有版本號，程式在每次啟動的時候，如果發現指令碼檔案有變化就會執行。

基於 SQL 的遷移

上面提到的幾種型別都是基於 SQL 檔案來執行的，只不過每種型別的命名格式不一樣，下圖是從官網上截下來的，大家看下每種型別的檔案應該按照如下的格式去命令，其中的 Separator 是兩個下劃線。

資料庫遷移神器——Flyway

主要分為下面幾個部分：

prefix：字首，不同的型別採用不同的字首，版本遷移使用 V，撤銷遷移使用 U，可重複遷移使用 R，當然這些都是可配置的；

Version：版本號，可以使用點符號或者單下劃線連結；

Separator：分隔符，兩個下劃線，也是可以配置的；

Description：版本描述可以用下劃線和空格分隔；

Suffix：字尾，一般都是 .sql

SpringBoot 專案接入 Flyway

SpringBoot 專案接入 Flyway 非常簡單，主要分為如下幾步即可，我們依次來看一下。

加入依賴

 <!-- flyway -->
 <dependency>
     <groupId>org.flywaydb</groupId>
     <artifactId>flyway-core</artifactId>
 </dependency>

在專案 pom.xml 檔案中加入上面的依賴即可。

增加配置

# 啟用 flyway
spring.flyway.enabled=true
# 禁止清理資料表
spring.flyway.clean-disabled=true
# 是否已經有資料庫
spring.flyway.baseline-on-migrate=true
# 基礎版本號，依次遞增
spring.flyway.baseline-version=0
# 遷移指令碼的存放的位置
spring.flyway.locations=classpath:db/migration

這裡因為很多情況下我們並不是一個新專案就開始使用 Flyway，而是專案在迭代中才引入的，所以上面的配置spring.flyway.clean-disabled=true 一定要禁用。上面幾個配置由於已經繼承到 SpringBoot 中了所以配置起來十分簡單。

遷移指令碼檔案

指令碼的命名規則按照上面說的，我們這邊採用版本遷移。我們建立一個版本的 SQL 檔案放到對應的類路徑資料夾裡面，檔名叫V1.2__create_test_table.sql，檔案內容如下，然後我們啟動專案。

CREATE TABLE `test_table`  (
  `id` int(11) NULL COMMENT 'ID',
  `name` varchar(255) NULL COMMENT 'Name'
);

啟動過程中我們看到如下日誌，顯示了當前的版本，以及遷移的版本。

資料庫遷移神器——Flyway

我們再檢視資料庫，首先 test_table 已經建立成功了

資料庫遷移神器——Flyway

另外我們在檢視flyway_schema_history 表，會發現已經多了一條版本資料，至此我們介入 Flyway 已經成功了。

資料庫遷移神器——Flyway

總結

今天阿粉給大家介紹了一個資料庫版本遷移的工具，這麼好的工具大家趕緊用起來吧，這樣在以後的版本迭代的過程中再也不會忘記執行SQL 了。這篇文章先跟大家介紹 Flyway 的使用，下篇文章我們再分享它的實現原理。

相關文章