磯部 和広
k-iso****@rozet*****
2013年 11月 7日 (木) 19:10:41 JST
いつもお世話になっております。 ＞弊社のマスターサーバーでも、以前、同様に突然リスタートしました。 ＞同様に、 ＞ mysqld got signal 11 ; ＞となっていて、全然原因が判りませんでした。 昨日、同様に mysqld got signal 11 ; となってMySQLが再起動しました。 前回の時は、/var/syslog/messageに Aug 29 12:29:52 DB128 kernel: mysqld[38361]: segfault at 7f06b59070a0 ip 00007f10950b8807 sp 00007f06dd400920 error 4 in libgcc_s-4.4.7-20120601.so.1[7f10950a9000+16000] 今回は Nov 6 18:31:56 DB131 kernel: mysqld[25948]: segfault at 7f9c104c20a0 ip 00007fa5efb6c807 sp 00007f9a9bb58c20 error 4 in libgcc_s-4.4.7-20120601.so.1[7fa5efb5d000+16000] と書かれていました。 OSS Message Pedia <command[pid]>: segfault at address... http://ossmpedia.org/messages/linux/2.6.9-34.EL/56980.ja どちらのケースも error 4 なので ユーザモードで メモリ読み込みの際に ページが見つからなかった というタイプですね。 今回は、mroongaのDBへのアクセス処理でエラーが発生したとの事です。 ※前回は、良く判らなかったそうです。 状況としては ・ラッパーモードのmroongaのテーブルに トランザクションを掛けて大量insertの最中にシグナル11でDBが再起動。 ・「大量インサート」の内訳は、７千行以上のデータを100行ずつに分割し トランザクションを掛け、100行insertし、commitを連続して行う処理で １回目のトランザクションでDBが再起動したそうです。 ・再起動後のDBに対してアプリが再接続し、トランザクションを終了させよう とするも トランザクションが失われているのでコミットもロールバックも出来ない という状況だったそうです。 その処理は、パフォーマンステスト用に いつも使う元データ を コードフリーズ後のアプリで の検収中に発生したので DBを殺すような不正な入力や処理があった訳ではない との事です。 また、該当時刻にmroongaのログは吐かれていませんでした。 ※ERRORログモードです。 何か解決の糸口になれば良いのですが・・・ 今回のマシンも前回と同じく mysql55-mroonga-3.06-1.el6_19.wing.x86_64 です。
