Два очка:
Нет ничего плохого в удалении миграций, которые больше не нужны, вы не должны хранить их вечно.
При необходимости вы можете обновить таблицу 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
)
Таким образом, вы можете подключиться к PostgreSQL, используя psql, создать таблицу вручную, а затем выполнить набор insert into schema_migrations (version) values (...), чтобы охватить исторические миграции, которые должны были быть выполнены в вашей промежуточной среде, а затем db:migrate как нормально, чтобы получить вещи в курсе. Затем вы можете потратить столько времени, сколько захотите, после вскрытия, чтобы выяснить, что случилось с таблицей schema_migrations вашей промежуточной базы данных.
Если вы пойдете по этому пути, вы, возможно, захотите взглянуть на таблицу ar_internal_metadata, если ваша версия Rails использует ее.
Вы, конечно, сделаете резервную копию своей промежуточной базы данных, прежде чем делать что-либо из этого. И вы захотите проверить свою производственную базу данных, чтобы убедиться, что она не испытывает те же проблемы.
Иногда вам нужно испачкать руки, чтобы дела пошли.