MySQL 5.6への移行でmysqldumpを使わなかったらどうなるか

MySQL 5.6へのアップグレードはmysqldump推奨 なんですが、それを無視してmysql_upgradeでアップデートできないものかと考える。というか、深遠な理由でmysql_upgradeでアップグレードしたMySQLが正に目の前にある。


【2014/03/19 11:13修正】

1) performance_schemaが使えない

5.5のperformance_schemaと5.6のperformance_schemaはテーブル構造が盛大に違うので、mysqldを起動させることはできるが盛大にエラーを吐く。performance_schemaにアクセスしようとするとクエリーがエラーになる。

mysqlスキーマの構造が違うのはmysql_upgradeがよしなにしてくれる(ので、InnoDB統計情報永続化とか、relay_log_info_repository= TABLEは使える)が、performance_schemaに関してはノータッチなのでこうなる。

【2014/03/19 11:27修正】

少なくとも5.6.16ではmysql_upgradeがよしなにやってくれているぽい。5.6.13で失敗したことがあったので 差を見てみると、scripts/mysql_fix_privilege_tables.sql というファイルが増えているので、ここかも知れない。ただ、5.6.13にも5.6.16にも scripts/mysql_system_tables.sql というのがあって、こっちでも同じようなことしてるっぽいんだよなぁ。。すいません。 そう思い込んでいたのかと。。ダメだ。。

ちなみに、5.6のmysql_install_dbをテキトーなディレクトリに向かって放ったあと、datadir/performance_schema をまるっとコピーして再起動したら直った(使えるようになった)が、これで本当に直ってるのか(他に影響が出ていないか)どうかは俺は知らない。。

2) TIMESTAMP, DATETIME型の方データ構造が微妙に変わっている

少なくともリファレンスマニュアル上でmysqldumpを推奨している理由についてリストアップされているのがこれ。マイクロ秒対応とかエンディアンが変わったとかパディング方式が変わったとか色々あるけれど、ただ使う分には問題なさげに動く。

例外は、「マスターはmysql_upgradeでアップグレードしたけど、スレーブはmysqldumpからリストアして構築した」もしくは「マスターはmysqldumpでアップグレードしたけど、スレーブはmysql_upgradeでアップグレードした」、かつ「バイナリーログがROWモードで記録された」場合。

これだと、マスターで記録された型情報とスレーブで再生されようとする型情報に不整合が発生するので、

mysql56> SHOW SLAVE STATUS\G
..
    Last_SQL_Errno: 1677
    Last_SQL_Error: Column 0 of table 'd1.t2' cannot be converted from type 'datetime' to type 'datetime'
..

こんな訳のわからない(datetime型からdatetime型への変換に失敗した)エラーでSQLスレッドが転ける。STATEMENTモードでは影響を受けないが、binlog_format= MIXEDでROWモードにフォールバックするようなクエリーが流れているとこれの直撃を食らう。

これは憶えておいた方がいいかも。