Rails部署中数据库迁移失败的处理方案咨询

问题背景 #

Rails单个迁移会被包裹在DDL事务中（以PostgreSQL为例），若单迁移中途失败，其所有变更会自动回滚。但一次执行多个迁移时，若其中某一个失败，已完成的前序迁移不会回滚，导致数据库处于部分迁移的不一致状态。比如部署5个迁移：

migration_1.rb
migration_2.rb
migration_3.rb
migration_4.rb
migration_5.rb

若migration_4.rb执行出错，migration_1.rb、migration_2.rb、migration_3.rb的变更会保留，引发生产环境问题。

你提出的初步方案是取消代码部署，通过rails db:rollback STEP=n（n为已成功执行的迁移数）回滚，但担心回滚过程中出错，以下是具体的解决思路：

一、事前预防：从根源减少失败概率 #

• 拆分迁移为单一操作单元：每个迁移只做一件事（比如仅添加一个字段、仅创建一张表），缩小失败影响范围，也让回滚更简单。
• 预演迁移验证：在 staging 环境复刻生产数据，提前执行所有待部署迁移，验证每个迁移的正确性、兼容性，提前排除潜在错误。
• 用大事务包裹多迁移（限支持事务化DDL的数据库）：Rails默认单迁移在事务中，但可自定义Rake任务将多个迁移放入同一事务，一旦某迁移失败，所有已执行操作都会回滚。示例任务：

namespace :db do
  desc "Run all pending migrations in a single transaction"
  task migrate_in_transaction: :environment do
    ActiveRecord::Base.transaction do
      ActiveRecord::Migrator.migrate(ActiveRecord::Migrator.migrations_paths)
    end
  end
end

执行时用rails db:migrate_in_transaction即可。注意：部分操作（如CREATE INDEX CONCURRENTLY）无法在事务中执行，需避开这类场景；同时确认数据库支持事务化DDL（如PostgreSQL支持，MySQL部分版本不支持）。

• 分批次部署迁移：不要一次性部署5个迁移，分多次执行，每次1-2个，验证无误后再执行下一批，降低风险。

二、事中处理：迁移失败后的应对步骤 #

如果已经出现部分迁移成功、后续失败的情况：

1. 立即暂停代码部署：避免新代码依赖未完成的迁移，引发更多连锁问题。
2. 排查失败根源：查看log/production.log或数据库日志，定位migration_4失败的具体原因（如字段冲突、数据约束不满足等）。
3. 尝试自动回滚：执行rails db:rollback STEP=3（对应前3个成功的迁移），若回滚成功，修复migration_4后重新执行所有迁移。
4. 回滚失败的应急处理：
   • 手动执行回滚SQL：如果某迁移的down方法有bug，直接通过数据库客户端（如psql）执行对应的回滚语句。比如migration_1是添加email字段，就执行ALTER TABLE users DROP COLUMN email;。
   • 修复迁移的down方法：修改对应迁移文件的down逻辑，确保能准确回滚up操作，再重新执行回滚命令。
   • 手动修正schema_migrations表：如果回滚完全无法进行，且确认数据库状态已恢复到迁移前，可手动删除schema_migrations表中对应成功迁移的版本记录（比如删除migration_1-3的版本行），让Rails认为这些迁移未执行。此操作需极度谨慎，必须确认数据库状态与迁移前一致。

三、事后优化：避免再次出现问题 #

• 完善迁移的down方法：每个迁移的down逻辑必须经过测试，确保能精准回滚up操作。
• 添加迁移验证逻辑：在迁移的up方法末尾添加验证步骤，比如检查字段是否存在、数据约束是否生效，确保迁移执行符合预期。
• 留存完整迁移日志：保留迁移执行的详细日志，方便后续排查问题。

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