如何实现Flyway多阶段部署及按需执行可重复迁移

关于可重复迁移的执行时机控制 #

Flyway本身没有提供「指定单个可重复迁移脚本单独执行」的直接参数，但完全可以通过两种落地方式实现你要的「按需触发、平时不跑」的效果，不用硬改Flyway核心逻辑：

• 拆分独立目录，通过locations参数控制扫描范围
  把所有清理类的R开头可重复迁移脚本单独存到独立目录，比如sql/cleanup，常规的版本迁移、业务相关可重复迁移放到默认的sql/migrate目录。
  普通发布时，执行migrate命令只指定常规迁移目录：flyway -locations=filesystem:sql/migrate migrate，这个过程根本不会扫描清理脚本目录，完全不会误触发清理操作。遇到需要执行清理的发布流程，先单独跑一次指向清理目录的migrate命令完成表清空操作，等中间的部署步骤走完，再切回常规目录执行后续的schema变更、数据写入脚本即可。
• 用占位符做执行开关，不用切换目录
  如果你不想拆分目录，可以在清理脚本里加占位符判断，通过启动传入的参数控制是否实际执行清理逻辑，示例写法：

  ${should_run_cleanup ? '
  -- 实际清理逻辑
  TRUNCATE TABLE log_table;
  DELETE FROM temp_config WHERE is_expired = 1;
  ' : '-- 本次发布跳过清理操作'}
  

  日常发布传参-placeholders.should_run_cleanup=false，脚本只会执行一行注释，没有任何实际库操作；需要跑清理的时候把参数值改成true就行。

这里提个容易踩的坑：可重复迁移的默认规则是，每次migrate扫描到对应脚本时，都会对比脚本当前checksum和历史表中记录的上次执行checksum，只要不一致就会重跑。只要你把清理脚本的触发逻辑管控好，完全不会出现每次发布都自动跑清理的问题。

关于修改可重复迁移脚本的报错问题 #

首先明确核心规则：可重复迁移（R开头脚本）本身就是设计为允许修改的，修改后不会像版本迁移（V开头脚本）那样直接抛checksum校验错误。
具体到你说的给清理脚本新增表、列清理逻辑的场景：

• 如果这个脚本修改后，是你第一次在当前环境触发执行，直接跑就行，Flyway识别到脚本checksum变化，会自动执行最新版本的内容，不会报错。
• 只有两种特殊情况需要用到flyway repair命令：
  • 之前执行这个清理脚本的时候中途报错失败，flyway_schema_history表里留了失败的执行记录，这个时候先把脚本逻辑改对，执行repair删掉失败记录，再重新触发迁移即可。
  • 你修改脚本只是调整注释、排版，没有改实际执行逻辑，不想让Flyway重跑这个脚本，就可以执行repair，把历史表里存的checksum更新成新脚本的checksum，下次扫描到就不会触发重跑。

别把V脚本和R脚本的规则搞混：V开头的版本迁移只要执行过一次就绝对不能改，改了必报checksum错，这种场景下的checksum不一致才是必须用repair处理的；R脚本改了之后自动重跑是正常设计，不是报错。

内容的提问来源于stack exchange，提问作者rafaborrego