マイグレーションをリセット して元のデータをリストアする時、以下の条件に当てはまるエンティティがある場合注意が必要です。

• ナビゲーションプロパティを持っている(→テーブルに外部キーが設定されている)状態でプロパティを追加した(特にshort, integer, long integer等整数型)
• エンティティ定義しているソースコードの最後以外の行にプロパティを追加し、Add-Migrationした(ソースコード上のプロパティの順番が追加していった順になっていない)

問題はカラムの順番です。何が起こるかというと、プロパティ追加前、テーブルにはナビゲーションプロパティの外部キーを保存するためのカラムがあります。特にKey属性などを設定してない場合、参照先のIdカラムと同じinteger型になるでしょう。ここに新しいプロパティを追加すると、カラムの順番の最後に入ります。

Id	integer primary key
Name	varchar(30)
NavigationId	integer (参照先のKeyカラムの型)
NewPropterty	integer

次にマイグレーションを整理してテーブルを作り直すと、ナビゲーションプロパティのカラムが最後に入ります。

Id	integer primary key
Name	varchar(30)
NewPropterty	integer
NavigationId	integer (参照先のKeyカラムの型)

リストアは作り直した空テーブルへの実行となりますから、mysqldumpにはno-create-info(-t)オプションを付けることになると思います。これで出力されるファイルにはカラムの順番情報がありません。リストア先のテーブルもId, Name, NavigationId, NewPropertyの順番でカラムが並んでいる前提になってます。

このダンプファイルを使って作り直したテーブルにリストアするとNewPropertyとNavigationIdの値が入れ替わって保存されます。NewPropertyがvarcharなどNavigationIdと異なる型になっている場合はエラーなどになるでしょうが、同じ型の場合エラーなく保存されます。外部キー整合性のチェックはリストア時には行われないようです(やったらめちゃくちゃ重くなりそうだし)。結果ナビゲーションプロパティはでたらめなデータを参照します。

上記の内容がよく分からない、マイグレーションを重ねすぎて条件に合致するか分からない場合は、complete-insertオプションを付けてmysqldumpを実行した方が安全です。ダンプ・リストア共に劇的に遅くなりますが。

昔の記憶ですがPostgreSQL(8.1)もダンプはこういう仕様(オプション付けないとカラムの順番を保存しない)だったような。テーブル大きいとダンプ・リストアも高速化したいですからねぇ。

保険のためにデータベースのフルダンプ(テーブル作成SQL込み)を取ってなかったら爆死だったな…

Update-Databaseを実行すると、なぜか対象のDBがフレッシュだと誤認→マイグレーションを最初から当てようとする→既に存在するテーブル名で作成しようとしてエラーとなる。

半日かけても原因が分からず、__MigrationHistoryが壊れてしまったのかもしれないと思い込むことにする。一度Rollbackなんてしたからその時おかしくなったのだろうか。

今回の変更は新規テーブルの追加のみだったのですが、カラム数と外部キーが多く手動はちとめんどくさいので以下の手段で。

1. MySQLに新しいデータベース(スキーマ)を作成。Entity Frameworkで用いるユーザーに必要な権限を与える。
2. App.configのConnection Stringを新しいデータベースを対象とするように書き換える。この時のApp.configは開始プロジェクトのもの。
3. Update-Database実行。新しいデータベースにテーブルが作成される。
4. 新しいデータベースからマイグレーションで追加されるテーブルと__MigrationHistoryをデータ付きでdump。

$ mysqldump -uroot -p -hlocalhost 新データベース名 __MigrationHistory 追加テーブル1 追加テーブル2 ... > migration.mysqldump

5. 既存データベースにリストア

$ mysql -uroot -p
mysql> use 既存データベース
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> drop table __MigrationHistory;
Query OK, 0 rows affected (0.82 sec)

mysql> source migration.mysqldump

ConnectionStringを元データベースに戻し、Update-Database -Scriptを実行(-Scriptオプションは実際に実行されないように)でさらに適用するマイグレーションが無いことを確認して完了。

[余談] 今回マイグレーションかける直前にmysqlのディレクトリのスナップショットを取ってあったので焦らずに済んだのですが、普段取らないのになぜ今回取る気になったのだろう？

[参考]

• mysqldumpの使い方 バックアップ＆リストア編 基本の章(ライズウィル)