Flyway

一.引言来在软件我的项目开发工程中，一般来说我的项目都是几个开发人员齐头并进的，经常遇到的事件是，大家都同时提交数据库表批改语句后，并不告知其它人，或者几个开发人员同时批改一个表构造，导致其他人运行我的项目出错。 还有在我的项目上线运行过程中，经常会因为治理数据库表构造或者表数据版本而发愁，甚至有的时候还不得不为生产数据做迁徙操作。 以上的问题，咱们个别的操作都是约定+脚本，但效率不高，并且经常会因为版本抵触，不得不手动merge。这个时候一个麻利工具，用于数据库的移植的Flyway利用而生，它的次要用于在你的利用版本一直降级的同时，降级你的数据库构造和外面的数据。 二、介绍来1. Flyway 的特色Flyway 大受欢迎是因为它具备如下劣势： 简略 很是容易装置和学习，同时迁徙的形式也很容易被开发者承受。专一 专一于用作数据库迁徙、版本控制而并无其它副作用。弱小 专为间断交付而设计，让Flyway在应用程序启动时迁徙数据库。2. Flyway 的工作机制Flyway 须要在 DB 中先建设一个 metadata 表 (缺省表名为 flyway_schema_history), 在该表中保留着每次 migration （迁徙）的记录, 记录蕴含 migration 脚本的版本号和 SQL 脚本的 checksum 值。下图示意了多个数据库版本。 对应的 metadata 表记录：spring installed_rankversiondescriptiontypescriptchecksuminstalled_byinstalled_onexecution_timesuccess11Initial SetupSQLV1__Initial_Setup.sql1996767037axel2016-02-04 22:23:00.0546true22First ChangesSQLV2__First_Changes.sql1279644856axel2016-02-06 09:18:00.0127trueFlyway 扫描文件系统或应用程序的类门路读取 DDL 和 DML 以进行迁徙。依据metadata 表进行查看迁徙。**若是脚本申明的版本号小于或等于标记为以后版本的版本号之一，将疏忽它们。其余迁徙是待处理迁徙：可用，但未利用。最初按版本号对它们进行排序并按程序执行 并将执行后果写入 metadata 表。 对应的 metadata 表记录：数据库 installed_rankversiondescriptiontypescriptchecksuminstalled_byinstalled_onexecution_timesuccess11Initial SetupSQLV1__Initial_Setup.sql1996767037axel2016-02-04 22:23:00.0546true22First ChangesSQLV2__First_Changes.sql1279644856axel2016-02-06 09:18:00.0127true32.1RefactoringJDBCV2_1__Refactoringaxel2016-02-1017:45:05.4251trueFlyway 反对命令行（须要下载命令行工具）和 Java Api ，也反对构建工具 Maven 和 Gradle 。这里咱们将眼光放在 Java Api 上。 ...

最近学习新项目时，数据库使用flyway进行管理的，之前并没哟使用过，第一次遇到有点懵，于是了解了一下。 官方文档 简介flyway是一款数据库迁移工具,在开发中，数据库需要迁移到很多不同的环境,开发环境，测试环境，生产环境等等。 通过备份来迁移数据库，你根本不知道你现在的数据库处于哪个状态，数据库升级脚本有没有执行成功，执行到了哪一步这些信息都不知道，在代码上有git可以进行版本控制，但是在数据库我们却没有什么很好的方式进行数据库版本管理和迁移。 使用flyway,就可以跟踪数据库版本的改变，明确数据库处于那个状态，并且以确定的方式从数据库的当前版本迁移到新版本。 原理当你使用flyway时，它会在数据库寻找一个历史版本的表,一般表名是schema_version,如果没有flyway会创建这么一个表，专门用来管理数据库的版本信息。 紧接着flyway会扫描类路径或文件系统下面的文件，可以是sql文件或java程序，根据版本号排序并执行。 每执行一个版本时，flyway都会在schema_version表中记录下这次升级，之后再执行中，对与表里已经存在的版本，下一次就不会再执行了。 通过这种方式，我们可以指定数据库的版本，并且每次数据库版本升级的信息都储存在数据库里，升级的内容是执行的sql文件，这样以来就可以追踪数据库版本的改变，迁移也都是自动完成。 使用中遇到的问题一开始不熟悉flyway，一遇到未知的问题就只能还原备份，后来我才发现，我遇到的flyway错误，一般都是运行的sql文件会与数据库已经确立的结构冲突，flyway遇到这种错误情况，就取消这次版本的升级，并且记录这次版本升级失败。比如当我执行这个1.3.0的数据库升级,想要在apply表中添加一个check_status字段: 但是执行时却失败了，控制台的报错是这样的: 它明确的告诉了失败的原因，错误sql脚本的位置、语句等，可惜我之前都没注意到。这里的失败是apply已经有一列check_status了，所以再添加一列相同的字段就会出错。可以把apply的这个字段删除就成功通过了。 在schema_version表中明确记录这次执行是失败的，success字段为0. 这样出错了就可以去查看排除，而不是一味地还原数据库了。 总结现在有越来越多强大的工具，合理运用可以帮助我们开发。

背景目前项目是spring boot+mysql+maven，因为需要数据库版本管理，因而集成flyway目标集成flyway对于已存在的数据库结构不影响步骤1.在pom.xml中加入依赖<dependency> <groupId>org.flywaydb</groupId> <artifactId>flyway-core</artifactId> <version>5.2.4</version></dependency>2.在项目中，创建放置sql的文件夹cd src/main/resourcesmkdir db/migration3.导出当前数据库的DDL和数据文件清空数据库导出数据库 mysqldump -uroot -p Mydb >Mydb.sql清空数据库drop database Mydb;create schema Mydb default character set utf8 collate utf8_general_ci;4.将导出文件放置到db/migration中mv Mydb.sql db/migration/V1__init.sql5.编译&&运行项目#编译打包mvn package#运行项目java -jar target/myproject-0.0.1-SNAPSHOT.jar 6.运行结果数据库和未集成前一致，且多一个schema_version表，该表是flyway进行版本管理的主表注意这个方法简单粗暴，用于比数据量不大的情况一些可以配置的flyway参数方法一：在application.properties 或者 application.yml 中配置# FLYWAY (FlywayProperties)spring.flyway.baseline-description=<< Flyway Baseline >> # Description to tag an existing schema with when applying a baseline.spring.flyway.baseline-on-migrate=false # Whether to automatically call baseline when migrating a non-empty schema.spring.flyway.baseline-version=1 # Version to tag an existing schema with when executing baseline.spring.flyway.check-location=true # Whether to check that migration scripts location exists.spring.flyway.clean-disabled=false # Whether to disable cleaning of the database.spring.flyway.clean-on-validation-error=false # Whether to automatically call clean when a validation error occurs.spring.flyway.connect-retries=0 # Maximum number of retries when attempting to connect to the database.spring.flyway.enabled=true # Whether to enable flyway.spring.flyway.encoding=UTF-8 # Encoding of SQL migrations.spring.flyway.group=false # Whether to group all pending migrations together in the same transaction when applying them.spring.flyway.ignore-future-migrations=true # Whether to ignore future migrations when reading the schema history table.spring.flyway.ignore-ignored-migrations=false # Whether to ignore ignored migrations when reading the schema history table.spring.flyway.ignore-missing-migrations=false # Whether to ignore missing migrations when reading the schema history table.spring.flyway.ignore-pending-migrations=false # Whether to ignore pending migrations when reading the schema history table.spring.flyway.init-sqls= # SQL statements to execute to initialize a connection immediately after obtaining it.spring.flyway.installed-by= # Username recorded in the schema history table as having applied the migration.spring.flyway.locations=classpath:db/migration # Locations of migrations scripts. Can contain the special “{vendor}” placeholder to use vendor-specific locations.spring.flyway.mixed=false # Whether to allow mixing transactional and non-transactional statements within the same migration.spring.flyway.out-of-order=false # Whether to allow migrations to be run out of order.spring.flyway.password= # Login password of the database to migrate.spring.flyway.placeholder-prefix=${ # Prefix of placeholders in migration scripts.spring.flyway.placeholder-replacement=true # Perform placeholder replacement in migration scripts.spring.flyway.placeholder-suffix=} # Suffix of placeholders in migration scripts.spring.flyway.placeholders= # Placeholders and their replacements to apply to sql migration scripts.spring.flyway.repeatable-sql-migration-prefix=R # File name prefix for repeatable SQL migrations.spring.flyway.schemas= # Scheme names managed by Flyway (case-sensitive).spring.flyway.skip-default-callbacks=false # Whether to skip default callbacks. If true, only custom callbacks are used.spring.flyway.skip-default-resolvers=false # Whether to skip default resolvers. If true, only custom resolvers are used.spring.flyway.sql-migration-prefix=V # File name prefix for SQL migrations.spring.flyway.sql-migration-separator=__ # File name separator for SQL migrations.spring.flyway.sql-migration-suffixes=.sql # File name suffix for SQL migrations.spring.flyway.table=flyway_schema_history # Name of the schema schema history table that will be used by Flyway.spring.flyway.target= # Target version up to which migrations should be considered.spring.flyway.url= # JDBC url of the database to migrate. If not set, the primary configured data source is used.spring.flyway.user= # Login user of the database to migrate.spring.flyway.validate-on-migrate=true # Whether to automatically call validate when performing a migration.方法二：用环境变量配置略参考资料Execute Flyway Database Migrations on Startupspring boot 开箱集成flywayExisting database setup ...