Flyway 資料庫遷移工具
Flyway 資料遷移工具
簡介
Flyway 是一個開源的資料庫遷移工具。相對於配置，它更傾向於簡單和約定。它基於 7 個基本的命令：
遷移可以使用 SQL（支援特定於資料庫的語法，如PL/SQL、T-SQL） 或 Java（用於高階資料轉換或處理 lob）編寫。
它有命令列客戶端,如果你在 JVM 上使用它，可以使用 Java API(也可以工作於 Android)應用於工程啟動的時候遷移資料庫。另外，你也可以使用 Maven 外掛或者 Gradle 外掛。
如果這還不夠的話，還有一些外掛可以用於 Spring Boot，Dropwizard， Grails， Play，SBT， Ant， Griffon，Grunt， Ninja 等等！
支援的資料庫有：
- Oracle
- SQL Server(包括 Amazone RDS 和 Azure SQL 資料庫)
- Azure Synapse
- DB2
- MySQL(包括 Amazon RDS 和 Azure 資料庫 和 Google Cloud SQL)
- Aurora MySQL
- Percona XtraDB Cluster
- TestContainers
- PostgreSQL
- Aurora PostgreSQL
- Redshift
- CockroachDB
- SAP HANA
- Sybase ASE
- Informix
- H2
- HSQLDB
- Derby
- Snowflake
- SQLite
- Firebird
為什麼要使用資料遷移？
首先，讓我們從頭開始，假設我們有一個叫做 Shiny 的專案，它的主要交付品是一個叫做 Shiny Soft 的軟體，它連線到一個叫 Shiny DB 的資料庫。如下圖：
我們有自己的軟體和資料庫。太好了，這很可能就是你所需要的。
但在大多數專案中，這種簡單的觀點很快就會轉化為：
我們現在不僅僅要從我們的環境中備份一次，而是多次，這帶來了許多挑戰。
我們已經很擅長在程式碼方面解決它們了
- 版本控制現在是通用的，每天都有更好的工具。
- 我們有可複製的構建和持續整合。
- 我們已經很好地定義了釋出和部署過程。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-nlyAxm6v-1602764850309)(https://flywaydb.org/assets/balsamiq/SoftGreen.png)]
關於資料庫應該怎麼做？
不幸的是，我們在這方面做得不是很好。許多專案仍然依賴於手動應用 SQL 指令碼。有時甚至不是這樣（這裡或那裡的快速 SQL 語句來解決問題）。很快就出現了許多問題：
- 這臺機器上的資料庫處於什麼狀態？
- 這個指令碼是否已經被應用？
- 生產中的快速修正是否已經應用到測試中？
- 如何設定一個新的資料庫例項？
上述問題的答案，往往是：不知道！！！
資料庫遷移是重新控制這種混亂局面的好方法
它們讓你：
- 從頭重新建立資料庫
- 在任何時候都要明確資料庫處於什麼狀態
- 以確定的方式從資料庫的當前版本遷移到較新的版本
Flyway 是如何工作的？
最簡單的場景就是將 Flyway 指向一個空的資料庫。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-VfIq9fdA-1602764850316)(https://flywaydb.org/assets/balsamiq/EmptyDb.png)]
它將嘗試定位它的例項歷史表。由於資料庫是空的，Flyway 將不會找到歷史，而是建立。
你現在有一個數據庫，預設情況下只有一個空表 flyway_schema_history：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-aGVU6IYw-1602764850317)(https://flywaydb.org/assets/balsamiq/EmptySchemaVersion.png)]
此表將用於跟蹤資料庫的狀態。
緊接著，Flyway 將開始掃描應用程式的檔案系統或類路徑以進行遷移。它們可以使用 SQL 或者 Java 編寫。
然後根據版本號對遷移進行排序，並按順序應用：
隨著每次遷移的應用，資料庫例項歷史表會相應地更新：
flyway_schema_history
| installed_rank | version | description | type | script | checksum | installed_by | installed_on | execution_time | success |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | Initial Setup | SQL | V1__Initial_Setup.sql | 1996767037 | axel | 2016-02-04 22:23:00.0 | 546 | true |
| 2 | 2 | First Changes | SQL | V2__First_Changes.sql | 1279644856 | axel | 2016-02-06 09:18:00.0 | 127 | true |
有了元資料和初始狀態，我們現在就可以討論遷移到新版本了。
Flyway 將再次掃描應用程式的檔案系統或類路徑以進行遷移。遷移將根據資料庫例項歷史表進行檢查。如果它們的版本號小於或等於標記為當前版本的版本號，則忽略它們。
其餘遷移是暫掛遷移:可用，但未應用。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-Cl0G1o0S-1602764850320)(https://flywaydb.org/assets/balsamiq/PendingMigration.png)]
然後按版本號排序，按以下順序執行：
相應更新模式歷史表：
flyway_schema_history
| installed_rank | version | description | type | script | checksum | installed_by | installed_on | execution_time | success |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | Initial Setup | SQL | V1__Initial_Setup.sql | 1996767037 | axel | 2016-02-04 22:23:00.0 | 546 | true |
| 2 | 2 | First Changes | SQL | V2__First_Changes.sql | 1279644856 | axel | 2016-02-06 09:18:00.0 | 127 | true |
| 3 | 2.1 | Refactoring | JDBC | V2_1__Refactoring | axel | 2016-02-10 17:45:05.4 | 251 | true |
這就是 Flyway ！每當需要更新資料庫時，無論是 DDL 還是 DML，只需建立一個版本號高於當前版本號的新遷移。下一次 Flyway 啟動時，它會找到它並相應的升級資料庫。