Flyway执行db repair后生成DELETE迁移致迁移失败，如何恢复？

Flyway的flyway repair命令核心作用是修复flyway_schema_history表的一致性问题。当它检测到以下情况时，会生成DELETE类型的迁移记录：

• 已执行的迁移脚本的checksum值与历史记录中存储的不一致
• flyway_schema_history表中存在状态异常的记录（比如标记为失败但实际已执行完成）
• 迁移脚本的文件名或版本号出现Flyway无法识别的变更

你遇到的情况，大概率是repair命令误判定原有迁移的历史记录不可靠，因此生成DELETE记录来"撤销"这些旧迁移的执行标记，导致Flyway认为这些迁移从未执行过，进而在后续运行时尝试重新执行。

你可以通过手动修正flyway_schema_history表来恢复原有状态，具体操作如下：

1. 备份历史表：先对flyway_schema_history表做完整备份，避免操作失误导致数据丢失：

   -- MySQL/PostgreSQL示例，其他数据库请调整语法
   CREATE TABLE flyway_schema_history_backup AS SELECT * FROM flyway_schema_history;
   

2. 定位DELETE记录：查询所有repair生成的DELETE类型记录，确认范围：

   SELECT * FROM flyway_schema_history WHERE type = 'DELETE';
   

3. 删除DELETE记录：将这些自动生成的DELETE记录从表中移除：

   DELETE FROM flyway_schema_history WHERE type = 'DELETE';
   

4. 校验原有迁移状态：确认剩余的迁移记录中，所有已成功执行的迁移的success字段值为1，type字段为对应的迁移类型（如SQL）。如果存在状态异常的记录，手动调整为正确状态。
5. 验证一致性：执行flyway validate命令，校验本地迁移脚本与flyway_schema_history表中的记录是否一致，确认无问题后再执行后续迁移操作。

• 不要随意执行flyway repair命令，仅当明确遇到flyway_schema_history表一致性问题（如迁移失败后残留脏记录）时再使用
• 如果DELETE记录的生成是因为迁移脚本被意外修改，需先将脚本恢复到与历史记录checksum匹配的版本，再执行上述修复步骤

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