Liquibase 4.30.0版本迁移脚本重复执行问题解析

问题现象

近期Liquibase社区报告了一个在4.30.0版本中出现的严重问题：当用户从4.29.2版本升级后，系统会错误地重新执行已经应用过的数据库迁移脚本，导致诸如"表已存在"、"列已存在"等错误。这个问题影响了使用Spring Boot集成和Gradle构建工具的用户环境。

问题根源

经过技术团队深入分析，发现问题源于4.30.0版本对变更集ID生成逻辑的修改。在之前的版本中，对于直接包含的SQL文件，Liquibase会使用"raw"作为ID前缀。但在4.30.0版本中，当include标签的file属性以斜杠("/")开头时，系统会将完整文件路径作为ID的一部分。

这种变化导致了ID生成不一致：

• 旧版本生成的ID格式：raw
• 新版本生成的ID格式：raw_文件名

由于Liquibase依赖ID来识别变更集是否已执行，这种ID格式的变化使得系统无法正确识别已经执行过的脚本，从而错误地重新执行它们。

解决方案

目前有两种可行的解决方案：

1. 临时回退方案：将Liquibase版本降级回4.29.2，这是最快速的解决方法。

2. 长期修复方案：修改include标签的file属性格式，避免使用绝对路径或classpath:前缀。例如：

   • 问题格式：<include file="/db/changelog/script.sql"/>
   • 问题格式：<include file="classpath:database/migration/script.sql"/>
   • 正确格式：<include file="db/changelog/script.sql"/>

技术背景

Liquibase通过DATABASECHANGELOG表来跟踪已执行的变更集。每个变更集的唯一标识由三个部分组成：

1. 变更集ID（id属性）
2. 作者（author属性）
3. 变更日志文件路径

在4.30.0版本中，对文件路径处理逻辑的修改意外影响了ID生成机制，导致了这次兼容性问题。开发团队已经提交了修复代码，预计会在后续版本中解决这个问题。

最佳实践建议

1. 在升级Liquibase版本前，先在测试环境验证迁移脚本的执行情况
2. 保持变更日志文件路径的相对性，避免使用绝对路径
3. 定期检查DATABASECHANGELOG表中的记录，确保变更集ID符合预期
4. 对于关键系统，考虑在升级前备份数据库

总结

这次事件提醒我们，在数据库迁移工具升级时需要格外谨慎。虽然新功能带来了改进，但也可能引入意想不到的兼容性问题。作为开发者，我们应该：

1. 充分理解工具的工作原理
2. 建立完善的升级测试流程
3. 关注社区报告的问题和解决方案
4. 保持变更日志的简洁和一致性

通过遵循这些原则，可以最大限度地减少数据库迁移过程中的风险。