heroku run rails db:migrateをするとMysql2::Error: Table 'heroku_~~~~~' doesn't existとエラーが出る

Question

環境は
rails5.2
mysql2 '>= 0.3.18', '< 0.5'
です。

タイトル通りheroku run rails db:migrateでマイグレーションをを行うと

Mysql2::Error: Table 'heroku_6fd1933f15cb900.leagueagendas' doesn't exist: 
SHOW FULL FIELDS FROM `leagueagendas`
.
.ログ省略
.
ActiveRecord::StatementInvalid: Mysql2::Error: Table 'heroku_6fd1933f15cb900.leagueagendas'
 doesn't exist: SHOW FULL FIELDS FROM `leagueagendas`
.
.ログ省略
.
Caused by:
Mysql2::Error: Table 'heroku_6fd1933f15cb900.leagueagendas' doesn't exist
.
.ログ省略
.

と３つエラーを吐き出します。
このleagueagendasというのは自分がローカル(development)でアプリを作成していた際に作ったテーブルなのですが、色々あり(初心者であるため非効率なトライアンドエラーがかなり多いです。。。)削除してしまったものです。
一応rails d model Leagueagendaモデルの削除と

class Records < ActiveRecord::Migration[5.2]
  def change
    drop_table :leagueagendas
  end
end

とマイグレーションファイルを作成し、ドロップテーブルをしてテーブルも完全に削除したはずだったのですが、何故か参照されてしまっています。
そもそも何故このエラーが出ているのかも、どう対策すればよいのかも分かりません。
何かまだ残骸みたいなのが残っていて参照されているのでしょうか？
どうすればエラーが吐かなくなるでしょうか。。。ここ3日間くらいあと一歩のところでherokuへ自作のアプリをデプロイ出来ず悔しくて寝れないです。。。必要であればログや詳細を追記します。
宜しくお願い致します。

追記

#db/migrate
$ heroku run rake db:migrate:status
   up     20180808163127  Create players
   up     20180813083503  Create boards
   up     20180813091701  Create comments
   up     20180821170634  Create rankings
   up     20180824194141  Create latestleagues
  down    20180903181519  Rename away team id column to away team
  down    20180903182558  Rename titre column to agendateams
  down    20180904095543  Add team name to players
 .
 .
　down    20180924132219  Records
 .

$ bundle exec rake db:migrate:status 
   up     20180808163127  Create players
   up     20180809165129  ********** NO FILE **********
   up     20180813083503  Create boards
   up     20180813091701  Create comments
   up     20180814201902  ********** NO FILE **********
   up     20180819160958  ********** NO FILE **********
   up     20180819190626  ********** NO FILE **********
   up     20180821170251  ********** NO FILE **********
   up     20180821170634  Create rankings
   up     20180824194141  Create latestleagues
   up     20180902162610  ********** NO FILE **********
   up     20180903181519  Rename away team id column to away team
   up     20180903182558  Rename titre column to agendateams
   .
   .
 　up     20180924132219  Records
   .

Answer 1

こんにちわ。

leagueagendasモデルを作成するmigrationファイルはまだ存在していますか？
このmigrationファイルが存在しない状態で、drop_tableなどの変更を加えようとすれば、heroku本番環境ではleagueagendasテーブルがないので上記エラーがでるのでは？と思います。
その場合はleagueagendasテーブルを操作するmigrationファイルを消してあげれば解消するとは思いますが、DBの構成とmigrationファイルとで齟齬が出てしまうかもしれないので、気をつけてください。

もし、試行錯誤を繰り返してmigrationファイルが散らかってしまっているようであればsquasherなどのgemで一度整理するのも良いかもしれませんよ。（たとえ散らかっても、トライアンドエラーはとても良い試みですけどね！）
squasherは現在のdb schemaの状態を見て、不要なmigartionなどを整理するgemになります。
でも、本当はこういったgemを使うのであれば、migartionの仕組みをちゃんと理解してから使うのがおすすめです。

migrationの仕組みはそれほど難しくはありません。
少しググるとたくさん記事がhitしますが、少し下地のある人にはこの記事とかはとても簡潔にまとまっていて良いんじゃないかと思います。
scheme_migrationsの中身が見たければ、herokuであれば、

$ heroku run rake db:migrate:status

とかで見れますよ！理解の助けになるはずです。

Comments

[widget11]

ご丁寧なご回答ありがとうございます！今は出先なので家に帰って試してみたいと思います！

[widget11]

すみません。まだ出先から戻っていないのですが、追マイグレーションファイルを削除する際って普通に右クリックでエディタから削除しても大丈夫なのでしょうか？調べてみるとbundle exec rake db:rollbackをする必要がある等出てくるのですが。。。。

[h_daido]

そこがまさに私がいっている「DBの構成とmigrationファイルとで齟齬が出てしまうかもしれないので、気をつけてください」の部分になります。そこはケースバイケースなので、開発環境とheroku本番環境のschemaを見て見ないとなんともですね。「leagueagendasモデルを作成するmigrationファイルはまだ存在していますか？」の内容をチェックしてからのほうが安全と思います。

[widget11]

ありがとうございます。帰宅して確認致しました。怖くてまだファイル削除ができていません笑
まず端的に言いますと、leagueagendaモデルを作成するmigrationファイルはもう存在しておりません。念の為schema.rbも確認したのですが、テーブルも存在していませんでした。

質問内容の箇所を編集(heroku run rake db:migrate:statusとbundle exec rake db:migrate:status の実行ログ)したのですが、
heroku run rake db:migrate:statusを実行したらRename away team id column to away teamというマイグレーションファイルの箇所からずっとdownと表示されており、このマイグレーションファイルはもう存在しないそのleagueagendasテーブルのカラム名を変更したものです。
またその他、このleagueagendasテーブルに対する操作としては少し日付が立って、20180924132219 Recordsというファイルでleagueagendasテーブルに対してdrop_tableしております。
どういう順序で作業を進めていくか検討があまりついていないのですが、ローカルにある以上2つのleagueagendasテーブルに対して操作を行っているマイグレーションファイルを普通に削除し、もう一度heroku masterにpushし、heroku run rails db:migrateを実行するという流れになるのでしょうか。
マイグレーションファイルの概念を掴むのが難しいです。。。。
大変申し訳ございませんが、ご指南のほどを宜しくお願い致します。

[h_daido]

やはりマイグレーションファイルとDBの間で齟齬が発生してしまっていそうですね。

> どういう順序で作業を進めていくか検討があまりついていないのですが、ローカルにある以上2つのleagueagendasテーブルに対して操作を行っているマイグレーションファイルを普通に削除し、もう一度heroku masterにpushし、heroku run rails db:migrateを実行するという流れになるのでしょうか。

この方針で問題ないと思います。
* 削除するマイグレーションファイル内で他テーブルに対する操作をしていないか、念のため確認しておきてください。他テーブルに対する操作がある場合は、leagueagendasテーブルに関する操作箇所だけけしてください。

その後、予期せぬ問題を起こさないようにするため、以下を行なっておくとよりベターかと思います。
・本番DBのschemaと開発DBのschemaの差分がないかチェック
（例えば、本番DBにだけ予期せぬテーブルや絡むが残っているなどの現象を防ぐため）
・マイグレーションファイルを綺麗にする
（上記gemを使うのがおすすめです）
ま、これはnice to haveです。
作業に詰まったらまたコメントください。

[h_daido]

ちなみに...

heroku推奨としてはDBはpostgresとなっていたかと思います。
https://devcenter.heroku.com/articles/heroku-mysql
（わたしが運用しているサービスもpostgresで作っています）

なにかとaddonが充実しているので、スケールやbackupなどメンテナンスがラクなんですよね。
ただ、mysqlでないと使えないクエリもあるので（たとえばbulk update系など）一概には言えないのですが、これを機に変更するというのもありかと思います。一応ご参考までに。

postgresに変更するなら、開発環境もあわせたほうが良い（もちろんバラバラにすることもできますが、あまりおすすめできません）のでその点もご注意を。

[widget11]

ありがとうございます！本日も家に帰ったら確認致します。
ちなみにローカルでbundle exec rake db:migrate:status を実行した際に上にあるように、 ********** NO FILE **********と書いてある（おそらく不要だと思い手動で削除したもの）マイグレーションファイルがup状態になっているのですが、こちらは削除したほうがよいのでしょうか？
https://qiita.com/yukofeb/items/ce39c7aabbfdc16205ea
を見るとstatusをdownにして削除しているようなのですが、upのままでも直接右クリックなりターミナルからrmコマンドで削除してもいいのでしょうか？
postgress一考してみます！

[widget11]

ありがとうございます！！！！！！！！！！！！！！！！！！！！
おかげさまで無事アプリケーションをデプロイできました！！！
嬉しくて涙でました笑
本当に親切にご質問にご回答いただきありがとうございます！！！！

[h_daido]

よかったです！

> FILE **********と書いてある（おそらく不要だと思い手動で削除したもの）マイグレーションファイルがup状態になっているのですが、こちらは削除したほうがよいのでしょうか？

わたしは特にケアしなくてもここまで問題が発生しなかったのですが、たしかにqitaのリンク先にあるように、リファクタリングしたほうが安全かなとは思います。

ただ、おそらく問題が発生するフェーズとしては、DBをinitして再構築するケースなどと思います（例えば、新しい開発メンバーが入った時や、開発端末を入れ替えるときとか？）
なので、今はせっかくデプロイできたアプリの機能を修正するとか、もっと楽しいことを優先して、問題が発生した時や余裕ができたときにリファクタリングするのでも充分かなとは思います。

マイグレーションの概念掴むのはむずかしいですよね...。ただ、暇な時に少しずつ学んでいくと、railsの深淵の端に少し触れられたような気がしてたのしいですよ。理解してしまえばよくできた仕組みだと思えるはずです。

どちらのしても、初デプロイおめでとうございます！
herokuを選択されたのはとても良い選択だと思いますよ