各務 洋
kagam****@outwa*****
2018年 7月 27日 (金) 21:07:37 JST
お世話になります、各務です。 >> Master 側の mysqld が ここ1ヶ月で頻繁に crash するようになり、その後の >> 自動再起動時に毎回 Mroonga の Auto repair が failure になります。 > > 1ヶ月くらい前になにか変えたことはありますか？たとえば、なに > かのバージョンをあげたとか。 crash する頻度が上がってきたので、Mroonga と MySQL を上げた位なのです。 >> 発生時間は不定ですが、概ね負荷が高くなる際に発生。 >> 但し、Slave 側では発生しません。 >> 障害発生時に縮退させるため、Master / Slave は交互に入れ替えますが、 >> いずれも Master 側でのみ発生します。 > > なかなか興味深いですね。。。 > 更新はあるんですよね？ 更新はあります。 但し、cron で重い更新処理が入る時があるのですが、そのタイミングと一致 する訳でもないようなのです。 > マスターは同時に更新されて、スレーブは直列化された後に順番に > 更新されているからクラッシュしないとかかしら。 確かに。なんらかの更新が関わっているのだとは思うのです。 このサーバーにはデータベースが2個入っていて、片方(sierra_cms) のデータ ベースの Mroonga のテーブルは更新が随意行われていて、正直、よく壊れます。 もう一つ(ftext_cms)のデータベースはほぼ同じ schema ですが、追加が夕方 で削除が深夜の各1回／日の cron 処理で、4年以上今まで壊れた事が無かった ものが今回初めて壊れました。 削除の cron と crash した時間が近い事。また壊れた事から削除のタイミン グで crash したと考えていますが、前述の通り同時の更新ではないので、 単純な同時の更新ではないと思います。 > 念のためログ全体を見せてもらえますか？ > https://github.com/mroonga/mroonga/ にissueを作ってそこに添 > 付してもらった方がよいかも。 https://github.com/mroonga/mroonga/issues/208 これでいかがでしょうか？ >> ======= 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()というのがその前にでるはずなん > ですけどねぇ。 出てはいないですねぇ。 参考になるかは分かりませんが、ログの中に1回だけ malloc(): smallbin double linked list corrupted が出ています。 > groonga-debuginfoとmysql57-community-mroonga-debuginfoもイン > ストールしてもらえますか？もう少しバックトレースの情報が増え > るかもしれないんです。 何らかの対応が入った版の適用時に合わせて入れてみたいと思いますがどうで しょうか？ 現状のままで Mroonga を復活させるのはだいぶ厳しいです……。 というのも障害が発生すると、Mroonga のテーブルの SELECT が全部 Opening tables の状態で止まってしまって、全ての接続を使い切ってサービス が停止してしまうのです。 他の環境では発生していないので、なんらかの要因はあるとは思うのですが よく分からないのです。 ---- 各務 kagam****@outwa*****
