Kouhei Sutou
kou****@clear*****
2018年 7月 27日 (金) 18:19:20 JST
須藤です。 In <5b57f****@mx*****> "[groonga-dev,04642] mysqld が got signal 6 で crash する。" on Wed, 25 Jul 2018 13:02:16 +0900, 各務 洋 <kagam****@outwa*****> wrote: > Master 側の mysqld が ここ1ヶ月で頻繁に crash するようになり、その後の > 自動再起動時に毎回 Mroonga の Auto repair が failure になります。 1ヶ月くらい前になにか変えたことはありますか？たとえば、なに かのバージョンをあげたとか。 > 発生時間は不定ですが、概ね負荷が高くなる際に発生。 > 但し、Slave 側では発生しません。 > 障害発生時に縮退させるため、Master / Slave は交互に入れ替えますが、 > いずれも Master 側でのみ発生します。 なかなか興味深いですね。。。 更新はあるんですよね？ マスターは同時に更新されて、スレーブは直列化された後に順番に 更新されているからクラッシュしないとかかしら。 > 下記のログは直近にあったものから1件分を切り出した形です。 > 他も概ね同じような感じですが、何か必要な情報がございましたらご指摘いただけたらと存じます。 念のためログ全体を見せてもらえますか？ https://github.com/mroonga/mroonga/ にissueを作ってそこに添 付してもらった方がよいかも。 > 〜〜 crash 前には特に予兆が無い > 2018-07-20 00:12:58.117113|n|ab876780|mroonga 8.03 started. > 2018-07-20 00:12:58.125081|n|ab876780|log level is 'NOTICE' > 2018-07-20 00:13:18.332164|n|1c04e700|Auto repair is started: <./sierra_cms/tm_article_view> > 2018-07-20 00:13:19.433459|n|1c04e700|io(sierra_cms.mrn.0000146) collisions(1000/1): lock failed 1000 times これはクラッシュにロックが残留してしまったケースなので、自動 修復できなくてしょうがないんですよねぇ。無理やりロックを解除 すると壊れたデータベースになっちゃう可能性が高いんです。 > ======= Backtrace: ========= > /lib64/libc.so.6(+0x7b194)[0x7f6586eff194] > /lib64/libc.so.6(+0x7d0e5)[0x7f6586f010e5] > /lib64/libgroonga.so.0(grn_free_default+0x23)[0x7f62eae0e743] > /lib64/libgroonga.so.0(grn_obj_close+0x42b)[0x7f62eae2ee6b] > /usr/lib64/mysql/plugin/ha_mroonga.so(+0x217be)[0x7f63072f67be] > /usr/lib64/mysql/plugin/ha_mroonga.so(+0x21859)[0x7f63072f6859] > /usr/sbin/mysqld(_ZN15Item_func_match7cleanupEv+0x62)[0x87b6a2] 検索中（全文検索の後の後始末のとき）にクラッシュしているんで すよねぇ。でも、その中でgrn_obj_close()を直接呼ぶことはない んですよねぇ。grn_obj_unlink()というのがその前にでるはずなん ですけどねぇ。 groonga-debuginfoとmysql57-community-mroonga-debuginfoもイン ストールしてもらえますか？もう少しバックトレースの情報が増え るかもしれないんです。 でも、検索中にクラッシュしてもロックは残らないと思うんですけ どねぇ。検索中はロックをとらないので。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート： http://groonga.org/ja/support/ データ処理ツールの開発： http://www.clear-code.com/blog/2018/7/11.html
