Cordapp场景下如何将旧Liquibase迁移脚本替换为新脚本

你的顾虑是对的：直接用「建新表迁数据删旧表+移除旧脚本」的方案不仅冗余，还会触发Liquibase校验失败——因为DATABASECHANGELOG里留存的旧变更集记录，会和你移除后的脚本文件不匹配，后续执行liquibase validate或任何变更操作时，都会因找不到对应脚本报错。这里给你一套更优的平滑迁移方案，无需改动现有数据：

核心思路 #

利用Liquibase的变更集标识匹配和预条件机制，在不破坏现有变更追踪的前提下，完成脚本结构的拆分切换。

具体步骤 #

• 保留旧的abc-init.xml，但清空里面的实际执行逻辑（可留注释说明已拆分），必须保证文件路径、文件名、原变更集的id和author完全与原文件一致。这样Liquibase校验时能找到对应文件，不会因找不到旧变更集脚本报错。
• 将原abc-init.xml中的表创建逻辑，完整拆分到新的abc-v1.xml和各个table-v1.xml中。给每个新表创建的变更集添加预条件，确保仅当表不存在时才执行：

  <preConditions onFail="MARK_RAN">
    <not>
      <tableExists tableName="你的表名"/>
    </not>
  </preConditions>
  

  已执行过旧脚本的环境中，新变更集会被自动标记为已执行，不会重复建表；全新环境则会正常执行创建逻辑。
• 修改abc-master.xml，同时引入旧的abc-init.xml和新的abc-v1.xml。等所有生产/测试环境完成切换、确认旧脚本不再需要后，再做收尾：
  1. 执行liquibase changelogSync命令，将新变更集记录同步到DATABASECHANGELOG中；
  2. 备份数据库后，手动删除DATABASECHANGELOG中旧变更集的记录；
  3. 最终移除abc-init.xml文件。

关键注意事项 #

• 绝对不要直接修改DATABASECHANGELOG中的现有记录，这会破坏Liquibase的变更追踪可靠性。
• 拆分后的每个table-v1.xml保持原子性，仅对应单个表的创建逻辑，方便后续维护和版本迭代。
• 先在测试环境验证整个流程，确保数据正常、Liquibase校验无报错后，再推广到生产环境。

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