pageが壊れる事象が発生している。利用したのは次のバージョンのMySQL5.6系。5.6.19-2.el6MySQLを利用しているLAMPアプリがエラーになり、妙なエラーが出ている。78/var/log/mysql.logを見てみると、次のようなログ出力され、ログも肥大化している。backup.3回目に壊れた時。6a4923b70000fdd60000fb450001007700000003da08b71645bf000000000000000000000420005e3f208177007e002c0000000201730174000000000009fa66000000000000000007bc00000000000000000000000000000000000000000100020047696e66696d756d0005000b00007375707どちらも、同じDB・テーブルのINDEXが格納されているPageのようだ。|+------------+-------+----------+----------------------------------+このテーブルには次のようなカラムとINDEXがある。(`host`(100))にしたが、再度壊れた。(`host`(100))あるいは、DISKが壊れかけていて、格納したデータが本当に壊れているのかもしれない。このDB・TABLEはこのサーバーの中でも最も大きいDBなので、そのDISK領域にぶつかりやすいのか?しかし、必ずINDEXというのもヘンである。データ領域が壊れてもおかしくない。MySQLのConfigがよろしくないのかもしれない。復旧させて、様子を見ることにしました。MySQLを復旧させた手順は次の通り。1度目は全Databaseをダンプ、リストアしたが、今回は該当のTABLEのみで復旧できた。DatabaseMySQLのSlaveサーバーのレプリケーションを止める。/etc/my.cnfを書き換え、mysqlを再起動する。restart壊れたTABLEをダンプする。password:何かテーブルが壊れるような要因がありそうなら、変える。今回は、urlのindexサイズを小さくしてみた。CHARSET=utf8;/etc/my.cnfをinnodb_force_recoveryを外し、mysqlを再起動する。[mysqld]#log-bin=mysql-bin※復旧時にバイナリログが不要ならlog-binをコメントにする。restart※これをやらないと、Tableをインポート時にエラーが発生した。0.Tableをインポートする。password:/etc/my.cnfをlog-binを戻し、mysqlを再起動する。restartMySQLのSlaveサーバーのレプリケーションを再度開始。原因がわからないので、また再発した場合の復旧メモとして記録しておこう。追記)その後、2回MySQLのDBが同様にクラッシュ。yumでアンインストール・再度MySQLをインストール・DBリストアを行ったところ、クラッシュしなくなった。