Flyway helps database script automation management strategy

Original address: Liang Guizhao's blog

Blog address: http://blog.720ui.com

Welcome to the official account: "Server Thinking". A group of people with the same frequency, grow together, improve together, and break the limitations of cognition.

Today, we will discuss an interesting topic: we can implement project version control through Git; continuous integration through Jenkins, then for the database level, we still rely on running SQL scripts purely by hand. For this, we use multiple environments (development environment, How to ensure the up-to-dateness and correctness of its SQL scripts in test environment, staging environment, production environment)?

<br /> As we all know, manual operations are very prone to problems, we should let the program help automate management and migration. Today, the author recommends Flyway, an open source database migration tool.

Flyway can not only support MySQL, it can also support many other databases. <br />

In fact, Spring Boot has perfectly integrated Flyway. For this, we can use it very conveniently. First, we introduce Maven dependencies. (Note that we also need spring-boot-starter-jdbc, mysql-connector-java dependencies in our project)

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

Additionally, we configure the relevant options in application.yml. Spring Boot scans Migrations by default in the classpath://db/migration directory. Here, the author adjusts it to db/sql through spring.flyway.locations.

spring:
  flyway:
    enabled: true
    baseline-on-migrate: true
    locations: [classpath:db/sql]

When the system program starts, it automatically creates the flyway_schema_history file. (Of course, you can also manually create it yourself). This table is Flyway's metadata table, which saves the records of each migration, including the version number of the migration script and the checksum value of the SQL script. When a new SQL script is scanned, Flyway parses the version number of the SQL script and compares it with the metadata table. If the version of the SQL script is updated, the SQL file will be executed on the specified DB, otherwise the SQL will be skipped document.

CREATE TABLE `flyway_schema_history` (
  `installed_rank` int(11) NOT NULL,
  `version` varchar(50) DEFAULT NULL,
  `description` varchar(200) NOT NULL,
  `type` varchar(20) NOT NULL,
  `script` varchar(1000) NOT NULL,
  `checksum` int(11) DEFAULT NULL,
  `installed_by` varchar(100) NOT NULL,
  `installed_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `execution_time` int(11) NOT NULL,
  `success` tinyint(1) NOT NULL,
  PRIMARY KEY (`installed_rank`),
  KEY `flyway_schema_history_s_idx` (`success`)
)

Then, we manually create an initialization SQL script under db/sql: V1.1__INIT_DB.sql.

DROP TABLE IF EXISTS `tag`;

CREATE TABLE `tag` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `gmtCreate` date DEFAULT NULL,
  `gmtModified` date DEFAULT NULL,
  `title` varchar(32) DEFAULT NULL,
  `parentId` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Well, after the program starts again, it will automatically publish it to the database.   

Here, additional knowledge points: Flyway's version comparison rules. It adopts the principle of left alignment, and replaces the missing position with 0. For example, version 1.1 is higher than version 1.0, version 1.1.1 is higher than version 1.1, and versions 1.1.01 and 1.1.1 are the same. Also, they are sorted by version and executed sequentially.

In addition, Flyway supports not only DDL, but also DML (insert, update, delete), etc. Therefore, we can create another V1.2__INSERT_TAG_DATA.sql file to verify.

INSERT tag(title, parentId) values('java', 0);
INSERT tag(title, parentId) values('spring', 0);

Finally, let's discuss the common types of migration that Flyway supports:

• Versioned migrations: Database upgrade scripts
• Repeatable migrations: Repeatable, re-executed when script checksums are changed.

• prefix: prefix identifier, the default value V means Versioned, R means Repeatable
• version: Identifies the version number, consisting of one or more numbers, the separator between the numbers can be dot. or underscore_
• separator: used to separate version identification and description information, the default is two underscores__
• description: description information, the text can be separated by underscores or spaces
• suffix: subsequent identifier, default is .sql

To sum up, Flyway helps us automate maintenance and management of database version migration through metadata (flyway_schema_history).

write at the end

[Server-side thinking]: Let's talk about the core technology of the server side, and discuss the project structure and practical experience of the first-line Internet. Let all the R&D personnel working alone find their own circle to communicate and discuss together. Here, we can upgrade our cognition, connect with the top technology giants, connect with excellent ways of thinking, connect with the shortest path to solve problems, connect with all excellent methods, and break the limitations of cognition.

More exciting articles, all in "Server Thinking"!

{{o.name}}

{{m.name}}