降级Rails后如何重新运行迁移？安全高效方案咨询

你的方案2（修改迁移版本号）完全可行，只要做好以下关键检查和步骤，就能安全高效地完成迁移且不丢失数据：

• 排查迁移的API兼容性
  逐行检查这4个Rails 7生成的迁移文件，确认有没有用到Rails 7专属的ActiveRecord迁移API：

  • 比如create_table的if_not_exists参数（Rails 6.1才引入，6.0.1不支持，需移除或改用原生SQL实现）
  • 比如add_column时使用的default: -> { 'CURRENT_TIMESTAMP(6)' }这类高精度时间默认值，Rails 6.0.1对部分数据库的支持可能有差异
  • 比如部分列类型的隐性行为变化，Rails 7对某些列操作做了优化，但Rails 6可能需要额外处理
    遇到不兼容的API，直接改成Rails 6.0.1支持的写法，比如把if_not_exists: true换成execute "CREATE TABLE IF NOT EXISTS ..."的原生SQL。

• 修改迁移版本标识
  找到每个迁移文件顶部的继承语句：

  class XxxMigration < ActiveRecord::Migration[7.0]
  

  把7.0改成6.0，这样Rails 6会用对应版本的迁移兼容层执行代码，避免语法或行为冲突。

• 强制备份数据库
  执行迁移前必须备份低环境的数据库，这是兜底保障：

  # PostgreSQL备份示例
  pg_dump -U 用户名 数据库名 > migrate_backup_$(date +%Y%m%d).sql
  # MySQL备份示例
  mysqldump -u 用户名 -p 数据库名 > migrate_backup_$(date +%Y%m%d).sql
  

  备份后可以尝试恢复到测试库，确认备份有效。

• 本地预验证
  在本地搭建和低环境完全一致的Rails 6.0.1 + Ruby 2.7.4环境，导入低环境的测试数据，把修改后的迁移文件放进去，运行rails db:migrate：

  • 检查是否有报错，比如列类型不兼容、语法错误
  • 对比迁移前后的schema.rb，确认表结构和预期一致
  • 测试核心业务功能，确保数据读写正常

• 低环境执行与验证

  1. 暂时停止低环境的应用服务，避免迁移过程中应用写入数据导致锁冲突
  2. 运行rails db:migrate，观察执行日志，确认4个迁移都成功执行
  3. 检查schema_migrations表，确认这4个迁移的版本号已被记录
  4. 重启应用，进行核心功能的冒烟测试，确保数据完整、业务正常

• 后续维护提示
  后续如果再次尝试升级到Rails 7，这些修改过版本号的迁移文件无需再调整——Rails 7会向下兼容ActiveRecord::Migration[6.0]的写法，不会影响升级流程。记得把修改后的迁移文件同步到代码仓库，保证所有环境代码一致。

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