Liquibase数据库变更管理中的重复记录问题分析

问题背景

在数据库版本控制工具Liquibase的使用过程中，开发者发现了一个与文档描述不符的行为。根据Liquibase官方文档，databasechangelog表中的记录应该基于id、author和filename三个字段保持唯一性。然而在实际操作中，当使用runAlways属性和preConditions onFail="MARK_RAN"组合时，系统会尝试插入重复记录，导致唯一键约束冲突。

问题重现

该问题在PostgreSQL 15.7数据库环境下可以稳定重现，具体表现为：

1. 首次执行变更集时正常记录
2. 添加唯一约束后再次执行相同变更集
3. 系统抛出重复键违反约束的异常

技术分析

深入分析问题根源，我们发现这与Liquibase内部处理变更集执行状态的机制有关。关键点在于：

1. runAlways属性：该属性指示变更集每次运行时都应执行
2. preConditions onFail="MARK_RAN"：当前置条件失败时，将变更集标记为"已标记运行"
3. ExecType状态机：MARK_RAN状态的ranBefore属性被设置为false

在MarkChangeSetRanGenerator中，由于ranBefore为false，系统会尝试插入新记录而非更新现有记录，这就导致了重复记录问题。

解决方案探讨

目前提出的解决方案虽然能避免重复记录问题，但存在一个明显的局限性：变更集的执行类型(exectype)在databasechangelog表中不会被更新为"MARK_RAN"。这意味着：

• 优点：解决了重复记录问题
• 缺点：无法准确记录变更集的真实执行状态

最佳实践建议

针对这一问题，我们建议开发者：

1. 避免在同一个变更集中同时使用runAlways和preConditions onFail="MARK_RAN"
2. 如需确保变更集每次运行，考虑使用runOnChange替代runAlways
3. 对于关键业务变更集，建议单独处理前置条件逻辑

总结

Liquibase作为强大的数据库版本控制工具，其内部状态机机制在处理复杂场景时可能出现预期外的行为。开发者在使用高级功能时应充分理解其内部工作原理，合理设计变更集，以避免类似问题的发生。同时，这也提醒我们在数据库迁移脚本中加入适当的约束和验证机制的重要性。