2019年7月30日火曜日

本番環境のデータをローカルのDBに投入したら UnknownMigrationVersionError と ProtectedEnvironmentError (Rails 5)

heroku上のアプリ からダウンロードしたデータをローカル(development)のDBに投入したところ、migration のバージョンが heroku上にあった物になってしまい、かつ、環境がプロダクションと認識されるようになってしまいました。

$ bin/rails db:rollback
rails aborted!
ActiveRecord::UnknownMigrationVersionError:

No migration with version number 201906********.

bin/rails:4:in `<main>'
Tasks: TOP => db:rollback
(See full trace by running task with --trace)

調べてみた所、migrationのバージョンの履歴は schema_migrations というテーブルに格納されていることが分かりました。

データベースを丸ごと投入したため、このテーブルも置き換わってしまい、DBに記録されているバージョン番号が現在Railsアプリにあるマイグレーションファイルの番号と一致しない状態になっていました。

参考: Ruby on Rails - マイグレーション履歴を削除して再実行したい|teratail
https://teratail.com/questions/176515

migration履歴はschema_migrationsテーブルに格納されているようですね


ではいっそ db:migrate:reset してしまおうとすると、今度は「Production環境ではこの操作はできません」的なエラー。

$ bin/rails db:migrate:reset
rails aborted!
ActiveRecord::ProtectedEnvironmentError: You are attempting to run a destructive action against your 'production' database.
If you are sure you want to continue, run the same command with the environment variable:
DISABLE_DATABASE_ENVIRONMENT_CHECK=1
bin/rails:4:in `<main>'
Tasks: TOP => db:migrate:reset => db:drop => db:check_protected_environments
(See full trace by running task with --trace)

でも確実にdevelopment環境のはず。もしかしてこの情報(productionかどうか)もDB上に保存されている?

こちらも調べてみたらまさにそうでした。

参考: Rails5でDBに自動生成されるテーブル、"ar_internal_metadata" とは何なのか - Qiita
https://qiita.com/EastResident/items/53c24340fd322758901f

"ar_internal_metadata" という見慣れないテーブルが存在している

Rails5から追加された新機能で、DBの不用意な削除を防止するための機能に必要なテーブルみたいです。

MySQL Workbenchでデータベースを見てみたら、 ar_internal_metadata テーブル、ありました。productionに置き換わってました。

今回は development 環境ということもあり、データを全削除しても問題なかったので
MySQLで appname_development のデータベースを丸ごとdropして、 bin/rails db:createbin/rails db:migrate し直しました。

これらの情報がDB上に保存されていることを知らなかったので、うっかり本番環境に接続してしまっていたかと焦りました。
(Railsアプリのどこかや環境変数で管理されていると思ってました。)

環境

Windows 10
Ubuntu 18.04.1 LTS (Windows Subsystem for Linux)
Ruby 2.5.3
Rails 5.2.1
MySQL 14.14

0 件のコメント:

コメントを投稿