こんばんは、yokuといいます。

このバグではないでしょうか？

http://bugs.mysql.com/bug.php?id=61104


ワークアラウンドとしては、innodb_change_buffering=inserts を指定するようです。

http://dev.mysql.com/doc/refman/5.5/en/innodb-performance-change_buffering.html


ts. yoku

2012年9月4日 17:53 Thuyoshi Nukii <nukii@xxxxxxxxxx>:
> 貫井（ぬきい）と申します。
>
> 複数のデータベースサーバをレプリケーション環境で運用していますが、
> スレーブサーバがアボートしてしまう事象が発生し困っており、皆様に
> アドバイスがいただければと思い投稿させていただきました。
>
> 環境
>   マスタサーバ
>     OS   ：RHEL 6.2 (x86_64)
>     MySQL：MySQL 5.5.19( 64 Bit版)
>
>   スレーブサーバ
>     OS   ：RHEL 6.2 (x86_64)
>     MySQL：MySQL 5.5.19( 64 Bit版)
>
>   ・レプリケーションは、行 ベース レプリケーションで行っています。
>   ・各サーバ間は、専用のGBitネットワークです。
>
>
>
> 現象としては、
> １．スレーブサーバが応答しなくなります。
>
> ２．DBサーバに稼働状況をか確認しに行くと、mysqldがプロセスとして
>     存在していない状況になっています。
>
> ３．mysqld_safeがmysqldを起動しようとする
>     起動することもありますが、以下のエラーで起動できないことが多
>     いです。
>
> ４．エラーログ上に残っている内容
> ibuf0ibuf.c line 4124
> InnoDB: Failing assertion: page_get_n_recs(page) > 1
> InnoDB: We intentionally generate a memory trap.
> InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
> InnoDB: If you get repeated assertion failures or crashes, even
> InnoDB: immediately after the mysqld startup, there may be
> InnoDB: corruption in the InnoDB tablespace. Please refer to
> InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
> InnoDB: about forcing recovery.
>
> ５．mysqldがアボートしていることに関してはエラーの出力はなく起動
>     に関するエラーしか残っていません。
>
> 以降は、innodb_force_recovery=4では起動できるので、データを抜き出
> して、削除してインポートするとレプリケーションも再開でき問題なく
> 稼働できます。
>
> ここ2ヶ月で複数台のスレーブサーバがアボートしていますが、同じサー
> バでの発生はないです。
> 各サーバのマスターサーバは別のものですので書き込みデータも違うも
> のです。
>
> マスター側は問題なく稼働しており、データ問題があるとも思えず原因が
> つかめない状況です。
>
>
> 以上、よろしくお願いいたします。
>
>
>