mysql:16053

yoku様

貫井（ぬきい）です


ご回答いただきましてありがとうございます。

今回、問題となったテーブルは、InsertとUpdateのみで運用しています
ので条件が合わないように思えます。

インデックスの項目が更新対象となっているので、このあたりでなにか
あるのですかね。

以上

(2013/11/13 11:27), yoku ts. wrote:
> こんにちは、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での不満は？」と訊かれ
>> 「不満はなく、高速化されており、安定しています」と回答したとたんに
>> こんな状況なっちゃいました。
>> 油断大敵です。
>>
>>
>>
> 


-- 
 株式会社 ベストリザーブ
   貫井 剛 （ぬきい つよし）

   mailto:nukii@xxxxxxxxxx
      URL:http://www.bestrsv.com
      TEL:06-6253-3800
      FAX:06-6253-3801