質問: デプロイ環境でrails db:migrateすると下記のようなエラーが出ます。 ``` Unknown table 'アプリ名_production.restaurants': DROP TABLE `restaurants` ``` localでrails db:migrate:statusを実行してDBの変更履歴を見ると以下のようになっています。 ``` up 20200116052507 Create posts up 20200116052828 Create places up 20200116111220 Add image to places up 20200117061424 ********** NO FILE ********** up 20200118113702 Devise create users up 20200118120853 Add nickname to users up 20200119075846 Add details to posts up 20200119080633 Add user id to posts up 20200121082518 Add column to users up 20200219114334 Remove tel from places up 20200219114621 Add prefecture to places up 20200219114902 Add description to places up 20200219115902 Drop table restaurants up 20200220103437 Create subplaces up 20200223114625 Remove restaurant from posts ``` 開発段階でrestaurantsテーブルというのを削除する際 ``` def change drop_table :[削除したいテーブル名] end ``` というマイグレーションファイルをmigrateしたのと、ターミナルでrails destroy model restaurant でモデルを削除しました。おそらくこの工程が影響して上記上から4つ目の up 20200117061424 ********** NO FILE ********** と 下から3つ目の up 20200219115902 Drop table restaurants が作成され、それらが作用してエラーが出ていると思われます。 dropする際のマイグレーションのコードも良くない書き方をしていたようで、ロールバックもできず困っています。 やはりロールバックできない状態だと、マイグレーションファイルの削除も変更もできないでしょうか? 上記2つのマイグレーションファイルを削除することができればエラーは解決すると思われるのですが、何かいい方法はあるでしょうか? ご教授お願いいたします。
回答: 1. 念のため、まずはローカル環境でDBのバックアップとリストアを練習しておくといいです。 2. ローカルの実験環境のDBのバックアップし、念のため別マシンや外部HDDなどにコピーを取っておきます。 3. マイグレート状態は「schema_migrations」に格納されているので、この場合「20200117061424」と「20200219115902」のレコードを実験環境で削除してください。 4. 「rails db:migrate:status」を実行すると、「20200117061424」はなくなり、「20200219115902」はdownになるはずです。そうなったら「db/migrate/20200219115902_drop_table_restaurants.rb」(ファイル名は違うかもしれませんので、先頭の「20200219115902」を確認してください)を削除または「.old」などを付加して実行されないようにします。 5. 再度「rails db:migrate:status」を実行すると、先ほどの2つはなくなって、全てupになるはずです。 6. 「rails db:migrate」で何も起こらなければ、整合性は取れているはずです。 7. デプロイ環境のDBのバックアップを取って、同様に外部にもコピーをしておきます。 8. 3.4.5.をデプロイ環境で実行すれば、DBがローカルのマイグレーション途中と同じ構成になるはずですので、6.でマイグレーションできるようになるはずです。 9. うまくいったら、他もテストして、問題ないか確認してください。 10. 問題があったら、一旦バックアップから戻して、再度最初から手順を確認してみてください。 こんな感じでできるはずですので、試してみてください。なお、デプロイ環境のDBのバックアップとリストアに自信がなければ、出来そうな人に手伝ってもらうようにして、デプロイ環境を破壊しないように注意した方が良いでしょう。