MySQL-5.6.20のDDLクラッシュ!

なにー!?

本当の原因はよくわかりませんが、
ローカルで MySQL を 5.6.20 にアップグレードして、
(ここでの話は全てコミュニティ版です)
create table やFK制約を貼るDDLを実行したら、
MySQLがクラッシュしました!

ReplaceSchemaでDDLを実行している最中なのですが、
途中でMySQLのプロセスが落ちて接続不可能に。
5.1.19だと大丈夫なのです。
これは、WindowsでもMacでも両方発生しました。

発生要因は?

発生しないプロジェクトもありました。
テーブルの数が多ければ発生しやすく、
少なければ発生しにくいように思えますが、
少なくても発生するケースもありました。

試しにどんどん落ちた箇所のDDLを削除して
DDLを特定しようとしましたが、
確かに落ちるDDLと落ちないDDLがあって、
でも、その区別が付かない。
そして、落ちるDDLは何個もある。
基本的に、FK制約を貼るDDLが落ちます。

検証しづらい

やっかいなのは、一度クラッシュすると、
MySQLの中のスキーマの状態がへんてこりんになるのか、
同じDDLがもう流せなくなります。
テーブルいないはずなのに既にあるよエラーとか。
FKないはずなのにFK制約違反とか。

なので検証は、つどつど新品のMySQLを差し替えます。
no-install のもので常に予備を用意しておきます。
でも、もともと ReplaceSchema を使っているので、
実行がとっても楽でDDL実行もトレースしやすいので、
その分は楽ですね。

また、現象もFK制約の付与自体が落ちるケースだけでなく、
付与は落ちないけれど、その後にdropとかDDLを流すと
なぜか drop table でクラッシュしました。
その後の挙動とか壊れ方は同じなので、
関連してるんじゃないかと。

エラーメッセージは?

クラッシュしちゃうので、
厳密にはエラーメッセージはありません。
MySQL起動したコンソールには、

mysqld got signal 11

と表示されて、プロセスは落ちています。

Windows環境だと、エラーログが吐かれていたようで、
MySQLのどのソースで落ちたとか情報があったようです。
そこから情報をもらって色々と「あたり」を付けてみて...

とにかく

まあ、バグっぽいわけですが、
回避できないかなぁと試行錯誤してて突き止めたのが...

FK制約名を入れてないと、つまり無名のFKだと発生する

というところでした。

でも、別にFK制約名をつけてないDDLがあるからって、
必ず発生するわけじゃない。

でも、とにかく

すべてちゃんとFK制約名つけていると発生しない

とまあ取り急ぎ、
同じように困った人がいたときのために報告でした。

それはそうとFK制約名は必須に

大丈夫なプロジェクトでは、
すべてのFKに対してFK制約名がしっかり付与されていました。
まあ、この問題とは無関係ですが、
FK制約名はしっかり付けてもらいたいなというところで、
ERMaster-b で、
FK制約名を必須にして、デフォルトでいい感じの名前が
付与されるようなプルリク送ろうかなぁって。