こんにちは、yokuといいます。

これの8/28 3:05の投稿が同じところでassertしてます。

貫井さんのクラッシュはSQLスレッドに起因するもののようですが(スタックの下の方がhandle_slave_sql)
InnoDB memcached Pluginもrowモードレプリケーションと同じように振舞うのかなぁとか思ったり。

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

storage/innobase/rem/rem0rec.cc:rec_get_offsets_func
という「レコードの中のどの位置にフィールドが置かれているか」を取る関数なので、
バグレポートのサブジェクトの通り
DROPやTRUNCATEした直後にrowモード(のSQLスレッド)でアクセスするとそうなるのかなーという感じがします。

いかがでしょう？ 心当たりとかありますでしょうか？


yoku ts.//

2013/11/12 Tsuyoshi Nukii <nukii@xxxxxxxxxx>:
> 貫井（ぬきい）と申します。
>
> 複数のデータベースサーバをレプリケーション環境で運用していますが、
> スレーブサーバがアボートしてしまう事象が発生し困っており、皆様に
> アドバイスがいただければと思い投稿させていただきました。
>
> 環境
>   マスタサーバ
>     OS   ：RHEL 6.2 (x86_64)
>     MySQL：MySQL 5.6.13(64 Bit版)
>
>   スレーブサーバ
>     OS   ：RHEL 6.2 (x86_64)
>     MySQL：MySQL 5.6.13(64 Bit版)
>
>   ・レプリケーションは、行 ベース レプリケーションで行っています。
>   ・各サーバ間は、専用のGBitネットワークです。
>   ・アボート発生時にデータベースへの接続は、無い状態でした。
>
> アボート時のログとしては、以下の情報が残っています。
>
> 以下の行から出力されたログです。
>
> InnoDB: Page directory corruption: infimum not pointed to
> 2013-11-11 05:01:57 7fc4dce2e700 InnoDB: Page dump in ascii and hex
> (16384 bytes):
>  len 16384; hex 『以下ダンプ情報１』
> InnoDB: End of page dump
> 2013-11-11 05:01:57 7fc4dce2e700 InnoDB: uncompressed page, stored
> checksum in field1 4044995124, calculated checksums for field1: crc32
> 170493788, innodb 1754970268, none 3735928559, stored checksum in field2
> 0, calculated checksums for field2: crc32 170493788, innodb 1693487627,
> none 3735928559, page LSN 1014 2635121547, low 4 bytes of LSN at page
> end 0, page number (if stored to page already) 618939, space id (if
> created with >= MySQL-4.1.1 and stored already) 64
> InnoDB: Page may be an index page where index id is 365
> InnoDB: (index "『インデックス名』" of table "『スキーマ名』"."『テーブ
> ル名』")
> InnoDB: Page directory corruption: supremum not pointed to
> 2013-11-11 05:01:57 7fc4dce2e700 InnoDB: Page dump in ascii and hex
> (16384 bytes):
>  len 16384; hex 『以下ダンプ情報２』
> InnoDB: End of page dump
> 2013-11-11 05:01:58 7fc4dce2e700 InnoDB: uncompressed page, stored
> checksum in field1 4044995124, calculated checksums for field1: crc32
> 170493788, innodb 1754970268, none 3735928559, stored checksum in field2
> 0, calculated checksums for field2: crc32 170493788, innodb 1693487627,
> none 3735928559, page LSN 1014 2635121547, low 4 bytes of LSN at page
> end 0, page number (if stored to page already) 618939, space id (if
> created with >= MySQL-4.1.1 and stored already) 64
> InnoDB: Page may be an index page where index id is 365
> InnoDB: (index "『インデックス名』" of table "『スキーマ名』"."『テーブ
> ル名１』")
> 2013-11-11 05:01:58 7fc4dce2e700  InnoDB: Assertion failure in thread
> 140483496175360 in file rem0rec.cc line 575
> 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.6/en/forcing-innodb-recovery.html
> InnoDB: about forcing recovery.
> 20:01:58 UTC - mysqld got signal 6 ;
> This could be because you hit a bug. It is also possible that this binary
> or one of the libraries it was linked against is corrupt, improperly built,
> or misconfigured. This error can also be caused by malfunctioning hardware.
> We will try our best to scrape up some info that will hopefully help
> diagnose the problem, but since we have already crashed,
> something is definitely wrong and this may fail.
>
> key_buffer_size=268435456
> read_buffer_size=2097152
> max_used_connections=6
> max_threads=1024
> thread_count=4
> connection_count=2
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 19150408 K  bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> Thread pointer: 0x7fc4a8000990
> Attempting backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong...
> stack_bottom = 7fc4dce2de20 thread_stack 0x40000
> /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x8fa385]
> /usr/local/mysql/bin/mysqld(handle_fatal_signal+0x3e8)[0x66cfd8]
> /lib64/libpthread.so.0[0x3eaac0f4a0]
> /lib64/libc.so.6(gsignal+0x35)[0x3eaa832885]
> /lib64/libc.so.6(abort+0x175)[0x3eaa834065]
> /usr/local/mysql/bin/mysqld[0x97eed6]
> /usr/local/mysql/bin/mysqld[0x960bc9]
> /usr/local/mysql/bin/mysqld[0x9ff5f1]
> /usr/local/mysql/bin/mysqld[0x9aa35d]
> /usr/local/mysql/bin/mysqld[0x9b8b64]
> /usr/local/mysql/bin/mysqld[0x999323]
> /usr/local/mysql/bin/mysqld[0x913139]
> /usr/local/mysql/bin/mysqld(_ZN7handler13ha_update_rowEPKhPh+0xb5)[0x58fcd5]
> /usr/local/mysql/bin/mysqld(_ZN21Update_rows_log_event11do_exec_rowEPK14Relay_log_info+0x11d)[0x88fc4d]
> /usr/local/mysql/bin/mysqld(_ZN14Rows_log_event12do_apply_rowEPK14Relay_log_info+0x2f)[0x8862ef]
> /usr/local/mysql/bin/mysqld(_ZN14Rows_log_event24do_index_scan_and_updateEPK14Relay_log_info+0x137)[0x890807]
> /usr/local/mysql/bin/mysqld(_ZN14Rows_log_event14do_apply_eventEPK14Relay_log_info+0xd30)[0x893c90]
> /usr/local/mysql/bin/mysqld(_ZN9Log_event11apply_eventEP14Relay_log_info+0x6d)[0x88b20d]
> /usr/local/mysql/bin/mysqld(_Z26apply_event_and_update_posPP9Log_eventP3THDP14Relay_log_info+0x17b)[0x8d14ab]
> /usr/local/mysql/bin/mysqld[0x8d1ff8]
> /usr/local/mysql/bin/mysqld(handle_slave_sql+0xcb9)[0x8d3319]
> /usr/local/mysql/bin/mysqld(pfs_spawn_thread+0x126)[0xac3886]
> /lib64/libpthread.so.0[0x3eaac077f1]
> /lib64/libc.so.6(clone+0x6d)[0x3eaa8e570d]
>
> Trying to get some variables.
> Some pointers may be invalid and cause the dump to abort.
> Query (0): is an invalid pointer
> Connection ID (thread ID): 2
> Status: NOT_KILLED
>
> ここまで、ログです。
>
> ・『』内は、内容を置き換え説明文をいれております。
> ・『インデックス名』は同じインデックスでした
> ・『スキーマ名』は同じスキーマでした。
> ・『テーブル名』は同じスキーマでした。
>
>
> このログ出力後、mysqld_safeからの再起動でデータベースは起動して
> います。
>
> 再起動時のログには、「InnoDB: Doing recovery」が実行されています。
>
> 以上、よろしくお願いします。
>
>
> 追伸：
> 先日、MySQL勉強会 in 大阪で話をさせていただくまでは安定稼働しており
> 講習会で、
> 「MySQL5.6での不満は？」と訊かれ
> 「不満はなく、高速化されており、安定しています」と回答したとたんに
> こんな状況なっちゃいました。
> 油断大敵です。
>
>
>