mysql:16053
From: Tsuyoshi Nukii <Tsuyoshi Nukii <nukii@xxxxxxxxxx>>
Date: Wed, 13 Nov 2013 12:23:21 +0900
Subject: [mysql 16053] Re: MySQL5.6.13のスレーブサーバがアボートしてしまう現象について
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 『以下ダンプ情報1』 >> 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 『以下ダンプ情報2』 >> 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 "『スキーマ名』"."『テーブ >> ル名1』") >> 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
16051 2013-11-12 18:52 [Tsuyoshi Nukii <nuki] MySQL5.6.13のスレーブサーバがアボートしてしまう現象について 16052 2013-11-13 11:27 ┗["yoku ts." <yoku0825] -> 16053 2013-11-13 12:23 ┗[Tsuyoshi Nukii <nuki] 16054 2013-11-16 13:14 ┗[舘山 聖司 <tateyan@x] 16055 2013-11-18 22:25 ┗[Tsuyoshi Nukii <nuki] 16057 2013-11-24 17:50 ┗[舘山 聖司 <tateyan@x] 16059 2013-11-26 15:26 ┗[Tsuyoshi Nukii <nuki]