おそらく私のところでは解決したのですが、情報として投稿しておきます。
先週ウチで運用していたWindows＋XAMPP環境で運用していたDrupalのサーバがシステム障害を起こし、新サーバへの引越し復旧を進めていました。
Drupal7です
そして元サーバと同じく最新版のXAMPPを新サーバにインストールし、
毎晩mysqldumpでバックアップしていた全データのダンプsqlをmysqlで復元しようとしたところ、
途中の特定の行で以下のエラーが出て進まなくなりました。
http://dba.stackexchange.com/questions/75328/row-size-error-with-mysql
ERROR 1118 (42000): Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
調べたところMySQL5.5よりInnoDBの仕様が変わり、SQL？の１行分のデータサイズの上限が厳しくなって再登録できずにエラーになったようです。
MySQL5.5 ⇒ 5.5 への移行で、同じバージョン同士なのに・・・
ダンプSQLを調べて、エラーになっていたテーブルは
cache_menu
の中の1行でした。
これはメニューの管理テーブル？一時テーブル？
確かにウチのDrupalではメニューや設定・コンテンツ等も頻繁に更新しておりデータ量が大きくなっていてもおかしくないのですが、
該当行をうっかり削除するわけにもいかず、やはり全ダンプデータを登録できる方法を探しておりました。
エラーメッセージの内容に従い、ROW_FORMAT=DYNAMICの記述をダンプSQLに追記しても状況変わりませんでした。
結局あまり上手な再設定方法が見つからず、
MySQL5.1が入っている少し前のバージョンのXAMPP（1.7.3）にインストールし直し、無事再登録ができました。
とりあえずウチのサーバはイントラなのでこれでいこうと考えております。
が、DrupalではこのMySQL5.5のInnoDBの仕様を回避できる実装が実現されていたりするんでしょうか。
知っている方がおられましたら情報いただけると助かります。
Comments
情報の共有ありがとうございます。 以下、報告していただいた
情報の共有ありがとうございます。
以下、報告していただいた問題に対する直接の解決方法ではないのですが、ご参考まで。
cache* テーブル内のレコードはキャッシュなので、truncate 等でレコードを削除しても問題なくリビルドされます。ですので、データベースダンプ作成時にそれらのテーブル内のデータは通常含む必要がありません。
cache* テーブルの構造だけを MySQL 5.5 に移行し、キャッシュがリビルドされた際に同じエラーが出ないようであれば問題ないと思います。
アドバイスありがとうございます。
ちょうど先日行ったのは仮サーバの一時避難なので、本番サーバが復元したときに
ご指摘のcache*を削除しての移行をテストしてみます。