无Teams Edition的Flyway社区版能否重置基线？如何操作

Flyway 7.5.4 社区版支持通过基线操作实现你需要的re-baseline效果，不需要Teams版本授权，对Snowflake数据库适配正常。操作完成后repair不需要再全量校验所有历史迁移脚本的checksum，耗时可以从数小时缩短到秒级。

核心逻辑：re-baseline本质是把当前schema的现有结构标记为指定版本的基线状态，后续Flyway只会执行版本号高于基线的迁移脚本，不再回溯校验基线版本之前的所有历史脚本记录。操作前必须确认当前schema结构和你选定的基线版本对应的结构完全一致，避免后续迁移出现结构冲突。

• 先确认新基线的版本号：取该schema最后一次成功执行的迁移脚本的版本号即可，比如最后成功执行的脚本是V9.4.1__add_user_table.sql，基线版本就设为9.4.1，确保后续要上线的所有迁移脚本版本号都高于这个值。
• 备份Flyway历史表：在Snowflake中对当前schema下的FLYWAY_SCHEMA_HISTORY表做克隆或者时间旅行备份，操作异常时可以快速回滚。
• 清空FLYWAY_SCHEMA_HISTORY表内的所有历史记录，注意不要删除表本身，仅删除表内数据即可。
• 修改Flyway运行配置：将flyway.baselineVersion参数设置为你前面确认的新基线版本号，关闭flyway.baselineOnMigrate自动基线配置，避免自动生成错误版本的基线。
• 执行flyway baseline命令，命令执行成功后Flyway会在历史表中插入一条基线标记记录，不会重新执行任何历史迁移脚本。
• 执行flyway info做校验：确认输出结果里基线版本标记正确，所有版本号低于基线的历史脚本显示为Ignored状态，版本号高于基线的待执行脚本状态正常。
• 校验通过后即可正常执行后续migrate、repair操作，此时repair只会处理基线版本之后的记录，不会再全量扫描校验所有历史脚本。

• 操作过程中暂时封锁对应schema的写入权限，避免其他任务修改表结构导致基线状态和实际结构不一致。
• 不要随意设置高于最后一次已执行脚本的基线版本号，否则会漏执行对应版本的迁移脚本，导致线上结构缺失。
• 如果是多环境共用的Flyway配置，执行完re-baseline后要同步更新所有环境的迁移脚本目录，避免其他环境执行时出现版本不匹配问题。

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