數據庫遷移神器——Flyway


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

前言

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

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

數據遷移

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

Flyway

Flyway 就是用來解決像這樣的數據庫遷移的工具,接入了 Flyway 過后,在數據庫中會生成一張默認名為flyway_schema_history 的數據表,用來追蹤數據庫的變化。程序啟動的時候 Flyway 都會在文件系統或者 classpath 路徑下面尋找遷移腳本。每個遷移腳步都有相應的命名規則,Flyway 會根據文件的版本號進行遷移,每次遷移過后都會在flyway_schema_history 表中插入一條類似如下的記錄,記錄版本已經對應的腳本文件和校驗碼等信息:

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

Flyway 的遷移類型

版本遷移

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

撤銷遷移

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

可重復遷移

可重復遷移有描述和校驗碼,但是沒有版本號,程序在每次啟動的時候,如果發現腳本文件有變化就會執行。

基於 SQL 的遷移

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

主要分為下面幾個部分:

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'
);

 

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

我們再查看數據庫,首先 test_table 已經創建成功了

另外我們在查看flyway_schema_history 表,會發現已經多了一條版本數據,至此我們介入 Flyway 已經成功了。

總結

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

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

前言

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

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

數據遷移

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

Flyway

Flyway 就是用來解決像這樣的數據庫遷移的工具,接入了 Flyway 過后,在數據庫中會生成一張默認名為flyway_schema_history 的數據表,用來追蹤數據庫的變化。程序啟動的時候 Flyway 都會在文件系統或者 classpath 路徑下面尋找遷移腳本。每個遷移腳步都有相應的命名規則,Flyway 會根據文件的版本號進行遷移,每次遷移過后都會在flyway_schema_history 表中插入一條類似如下的記錄,記錄版本已經對應的腳本文件和校驗碼等信息:

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

Flyway 的遷移類型

版本遷移

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

撤銷遷移

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

可重復遷移

可重復遷移有描述和校驗碼,但是沒有版本號,程序在每次啟動的時候,如果發現腳本文件有變化就會執行。

基於 SQL 的遷移

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

主要分為下面幾個部分:

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(11NULL COMMENT 'ID',
  `name` varchar(255NULL COMMENT 'Name'
);

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

我們再查看數據庫,首先 test_table 已經創建成功了

另外我們在查看flyway_schema_history 表,會發現已經多了一條版本數據,至此我們介入 Flyway 已經成功了。

總結

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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM