我正在尝试将新版本的项目部署到我的登台服务器，但数据库中的schema_migrations表格无法解释为空。
现在尝试在部署时运行所有迁移，导致问题，因为其他表存在且完好无损。
而不是删除/重新创建数据库并丢失所有数据（虽然不方便，一个有效的选项），是否可以生成schema_migrations表而不会丢失？
答案 0 :(得分：0)
两点：
删除不再需要的迁移没有任何问题，你不应该永远保留它们。
如果需要，您可以手动更新schema_migrations表。
就（1）而言，我删除了一个月左右的迁移（假设它们已经应用于所有地方）。在db/migrate中保持多年的混乱是毫无意义的。除了最近的迁移之外，向下迁移然后再向上迁移往往比它们的价值更加混乱。如果您需要测试旧的，请转储当前的开发数据库，并从较旧的schema.rb开始。此外，如果您确实需要旧的迁移，那么您可以随时将其从版本控制中删除，或者只是根据db/schema.rb（或db/structure.sql）版本之间的差异重新创建它。
当然，如果你没有将db/schema.rb保留在版本控制中，那么你做错了，你手上就会发生灾难。
对于（2），schema_migrations表非常简单：
create table schema_migrations (
version varchar not null primary key
)
因此，您可以使用psql连接到PostgreSQL，手动创建表，然后执行一堆insert into schema_migrations (version) values (...)来涵盖应该在您的暂存环境中运行的历史迁移，然后正常情况db:migrate让事情变得更新。然后，您可以花费尽可能多的时间进行验尸，以弄清楚临时数据库的schema_migrations表发生了什么。
如果您选择这条路线，如果您的Rails版本使用它，您可能需要查看ar_internal_metadata表。
当然，在执行任何此操作之前，您将备份您的临时数据库。并且您将需要检查您的生产数据库，以确保它没有遇到同样的问题。
有时你必须亲自动手才能把事情搞定。