flyway mysql乱码_Flyway学习笔记

对于降级操作(downgrade scripts/downward migrations)的支持

Flyway does NOT support downgrade scripts.

While the idea of downgrade scripts (popularized by Rails Migrations) is a nice one in theory, unfortunately it breaks down in practice. As soon as you have destructive changes (drop, delete, truncate, ...), you start getting into trouble. And even if you don‘t, you end up creating home-made alternatives for restoring backups, which need to be properly tested as well.

Flyway不支持降级的脚本：

一旦执行了诸如drop、delete、truncate这样的清除性动作，从之前的实验操作结果，我理解并不是说flyway不会甚至不能执行降级操作，毕竟drop、delete、truncate只是一些指令，flyway本身并没有能力看出来是哪些操作，这个回答应该是想说，最好不要做诸如此类的清除性动作，否则麻烦就来了，除非之前已经做了充分的备份以恢复数据。

Downgrade scripts assume the whole migration failed.

A migration can fail at any point. If you have 10 statements, it is possible for the 1st, the 5th, the 7th or the 10th to fail. There is simply no way to know in advance. Downgrade scripts are written to roll back an entire migration. This renders them effectively useless, even for non-destructive changes.

Migration执行失败可能发生在任何一个脚本，而降级操作相当于是在之前已经完成的基础上，那么如果前面的脚本执行失败，那么后面的操作就不会起作用，即便不是消除性操作。

我理解答案是想说明migration执行成功与否具有不确定性，而且版本号越高不确定性越强，因为会依赖先前的执行结果。

Maintain backwards compatibility between the DB and all versions of the code currently deployed in production.

This way a failed migration is not a disaster. The old version of the application is still compatible with the DB, so you can simply roll back the application code, investigate, and take corrective measures.

要确保数据库与线上各个版本代码的兼容性，才不会因为一次失败的migration脚本而造成重大损失。而且当真正执行失败的时候，也可以恢复回老版本的代码，再对错误做出修正。

A much better solution is a proper, well tested, backup and restore strategy.

It is independent of the database structure, and once it is tested and proven to work, no migration script can break it. For optimal performance, and if your infrastructure supports this, we recommend using the snapshot technology of your underlying storage solution. Especially for larger data volumes, this can be several orders of magnitude faster than traditional backups and restores!

这里是推荐在条件允许的情况下，用快照对已上线的系统做数据备份，说是比传统的数据备份与恢复要快。

如何做好热修复？

比如说现在已经上线的是版本7，正在开发的是版本8，而且版本8在DB schema上有些改动。此时有些bug导致需要对版本7做些热修复，也涉及到了schema的改动。

一般来说，虽然代码有多个分支，不过schema不会。所以可以将热修复的脚本标号为7.1，并且适用于修复版本7，和新的版本8。这样在版本8真正上线的时候，也会按照7、7.1、8的顺序执行脚本。

如果上述方案不行，还可以用outOfOrder(在flyway.conf有这个参数)属性，这样就可以允许不全部按照从小到大的顺序执行migration，也就是比schema_version中记录的最大值小的脚本，也能够被执行。

多个节点能够并行执行migration吗？

当然可以！Flyway使用数据库锁机制(locking technology of your database)来协调多个节点，从而保证多套应用程序可同时执行migration，而且集群控制也可做配置。

如果migration执行失败，会有回滚吗？

Flyway在不同的事物中执行migration，如果失败，那么事物就会回滚。不过不幸的是，现在只有DB2、PostgreSQL、Derby还有个别SQL Server扩展支持事物内的DDL。Other databases such as Oracle will implicitly sneak in a commit before and after each DDL statement, drastically reducing the effectiveness of this roll back. (没看太懂得一句)。一个可行的办法就是一个migration只包含单个DDL，只不过这样做比较累。

Flyway是否支持多schema？

当然支持！以下有几种策略来处理多schema的情况：

如果有多个相异的schema，可以用flyway的loop并且设置与schema对应的flyway.schemas。

如果schema的生命周期相同，那么可以只用一个flyway实例，设置flyway.schemas值为所有schemas以逗号隔开的字符串。所有的schema将只用到一个schema_version来记录脚本执行情况。(不知道此时schema_version表中会不会有专门的一列显示schema的名称)

如果schemas的生命周期不同，那就要启动多个flyway实例，每个实例处理自己的schema和metedata table，注意要把脚本分开放。