flyway迁移hsqldb到mysql_Flyway-数据库迁移工具

一.什么是Flyway?

该Flayway是一款专注于数据库版本控制与管理的专业工具软件；它提供自动化处理数据库版本升级的功能；Migrations这一核心模块既可采用SQL脚本的形式实现也可嵌入Java代码中；除了命令行界面及Java API接口的支持外；还提供了Build工具与Spring Boot框架的集成选项；同时该系统能在分布式计算环境中确保数据库的安全可靠升级；并且具备有效的故障恢复机制

Flyway的核心功能是负责维护版本演变历程和状态信息的数据Meta表，在首次运行时会生成一个默认名为SCHEMA_VERSION的数据元数据表。

为什么使用Flyway?

一般而言，在项目的初期阶段会对数据库进行整体规划。然而，在开发产品的新特性阶段中，则可能会遇到需要调整数据库Schema的情况。例如：创建新的表结构、新增字段以及新增约束等。这种情形在实际项目中也比较常见。

那么，在开发人员完成数据库SQL脚本更新后，请问：如何高效地在其他开发者的机器上实现同步操作？此外，在开发环境中，请问：如何快速实现对测试服务器的同步？最后，请问：如何确保集成测试能够顺利执行并成功通过？

在基于Spring Boot的技术项目中可能会认为：本地将使用Hibernate自动生成数据库Schema更新模式；测试团队（QA或DEV）将手动执行预编译的SQL脚本；开发人员可以编写一个Gradle任务来自动化处理这些更新。

个人认为，在使用Hibernate进行数据库自动更新时，
操作不够透明，
自由度较低，
容易导致错误发生。
例如：
当在SQL中定义某个字段为VARCHAR类型时，
在对应的Eclipse实体中将其配置为CHAR类型后，
在运行集成测试的过程中

默认生成的数据库表中的字段被默认定义为CHAR类型；然而这与SQL脚本预期的VARCHAR类型的字段存在差异。尽管测试结果表明这种差异不会直接影响功能（即测试通过了），但在实际运行中会导致错误（即本地bootRun环境或服务器上运行Service时都会出现故障）。

另外，在各个测试服务器上手动运行SQL脚本既耗时又费力。
为什么不自动化呢？
然而，在高级别和PROD环境中，
最后的想法是编写一个自动化的程序来完成更新操作；这主意很好。

那么既然已经提供了现成的插件或库来帮助实现这一功能

实际上此等问题可通过Flyway工具实现高效的解决方案主要通过其强大的功能特性支持自动化的数据库版本管理不仅支持自动化的版本控制还具备详细的版本更新日志记录特性。

二,怎么使用Flyway(这里使用Springboot整合Flyway)

配置Maven依赖项，并在可选属性中指定插件（其功能是无需启动项目即可执行Flyway的各种命令）

org.flywaydb

flyway-core

5.0.3

org.flywaydb

flyway-maven-plugin

5.0.3

在此时段期间，在双击状态下，在执行上图所示的flyway:migrate命令时，在启动整个工程执行migrate命令时的表现一致。

其它命令的作用如下列出，各位可自行实验体会：

baseline

为已有的具有Schema结构的数据库提供了一种解决方案。具体而言，在非空库中创建新MetaData表，并将Migrations应用于该库；另外，在现有架构的基础上实现新增MetaData表。

clean

从数据库模型中的全部实体出发，在开发和测试环境中进行清理工作时，请注意将涵盖表结构、视图以及存储过程等对象一并清除。该操作在开发环境中表现优异，在生产环境则必须禁止使用。

info

旨在生成全部的迁移操作所需的具体状态报告，并通过相应的Meta数据记录以及相关的Migrations执行来实现这一目标；同时能够迅速确定当前的数据库版本号。

repair

repair操作能够修复metaData表，该操作在metadata出现错误时很有用。

undo

撤销操作，社区版不支持。

validate

检查已经部署的迁移是否存在更改，默认情况下启用此功能。其原理在于比较本地迁移表与MetaData表中的checkNum字段。当该字段值与预期一致时，则验证成功；否则验证将失败。

2.编辑Flyway相关的配置文件

server.port=8088spring.datasource.url=jdbc:mysql://127.0.0.1:3306/testdb

spring.datasource.username=root

spring.dataSource.username = spring.dataSource.driverClassName = com.mysql.cj.jdbc.Driver

3.在classpath下新建/db/migration文件夹,用于存放SQL脚本

4.创建我们所需要的并且需要同步数据库的SQL脚本

注意文件的命名规则:

这里有两类文件:

仅需执行一次的SQL命名必须以大写字母V开头,随后接上由0到9组成的数字串,这些数字之间可用点号或下划线分隔;在其前后各加两个下划线,并紧跟文件名,.sql扩展名附加在文件名之后

如，V2.1.5__create_user_ddl.sql、V4.1_2__add_user_dml.sql。

支持反复执行的SQL语句，则应采用全大写“R”作为前缀，并通过双下划线分隔文件名，最后添加’.sql’扩展名。

比如，R__truncate_user_dml.sql。

其中，V开头的SQL执行优先级要比R开头的SQL优先级高。

usetestdb;CREATE TABLEperson (

idint(11) NOT NULLAUTO_INCREMENT,

firstvarchar(100) NOT NULL,

lastvarchar(100) NOT NULL,

dateofbirth DATEDEFAULT null,

placeofbirthvarchar(100) not null,PRIMARY KEY(id)

Use InnoDB engine with default charset as utf8 to insert a record into the person table. The record includes four fields: first name, last name, date of birth, and place of birth. Values to be inserted are 'Dursun' as first name, 'KOC' as last name, STR_TO_DATE('02/10/1982', '%m/%d/%Y') as date of birth, and 'Erzincan市' as place of birth. Repeat similar steps for inserting another record with values 'Durseeun' as first name, 'KeeOC' as last name, STR_TO_DATE('05/10/1982', '%m/%d/%Y') as date of birth, and 'Erzeeincan' as place of birth.

三.Flyway的配置清单

flyway.baseline-description对执行迁移时基准版本的描述.

在执行迁移操作时识别到目标schema非空且包含没有附加元数据的表的情况下，默认是否会触发基准迁移？默认设置为否。

flyway.baseline-version启动基准迁移过程对现有schema进行标记处理其默认值设置为1.

flyway.check-location检查迁移脚本的位置是否存在，默认false.

flyway.clean-on-validation-error在遇到验证失败时是否会自动触发clean操作，默认设置为false.

flyway.enabled是否开启flywary，默认true.

flyway.encoding设置迁移时的编码，默认UTF-8.

Upon attempting to read the metadata table, does the flyway configuration option flyway.ignore-failed-future-migration instruct the system to skip failed migration attempts? Defaults to false.

flyway.init-sqls当初始化好连接时要执行的SQL.

flyway.locations迁移脚本的位置，默认db/migration.

flyway.out-of-order是否允许无序的迁移，默认false.

flyway.password目标数据库的密码.

flyway.placeholder-prefix设置每个placeholder的前缀，默认${.

flyway.placeholder-replacementplaceholders是否要被替换，默认true.

flyway.placeholder-suffix设置每个placeholder的后缀，默认}.

flyway.placeholders.[placeholder name]设置placeholder的value

配置飞鸽模式（Flyway schemas）设置以实现用于跨平台迁移的模式架构，默认大小写敏感，并基于默认模式架构设计。

flyway.sql-migration-prefix迁移文件的前缀，默认为V.

flyway.sql-migration-separator迁移脚本的文件名分隔符，默认__

flyway.sql-migration-suffix迁移脚本的后缀，默认为.sql

flyway.tableflyway使用的元数据表名，默认为schema_version

flyway.target迁移时使用的目标版本，默认为latest version

当 flyway.url 迁移时若未做 flyway.url 配置，则采用配置中的主数据源作为 JDBC URL 使用。

flyway.user迁移数据库的用户名

flyway.validate-on-migrate迁移时是否校验，默认为true

参考文章: