Kouhei Sutou
kou****@clear*****
2017年 1月 26日 (木) 07:32:43 JST
須藤です。 In <CBD6B****@gmail*****> "[groonga-dev,04256] Mroongaストレージモードでmysqld got signal 11" on Tue, 24 Jan 2017 22:45:38 +0900, murata satoshi <murat****@gmail*****> wrote: > Mroongaストレージモードでmysqldがクラッシュすることがあるので報告します。 > *再現手順が確立できていない状態での報告となってしまい申し訳ありません。 いえいえ、報告ありがとうございます！ > - 上記core dumpの該当Threadで実行されていたのはmroonga_command経由でのselectですが、全文検索ではありません。(drilldown付き) > * SELECT mroonga_command('select xxx_tbl --filter "xx_column1==1&&xx_column2==0" --limit 0 --drilldown xx_column3 \ > --drilldown_filter _nsubrecs>=1 --drilldown_limit 32') AS result おぉ、（まだドキュメントに書けていないのに）drilldown_filter を活用している！ > - 上記core dumpでは他のThreadで更新処理は流れていませんでした(selectのみ、全文検索なし)。 普段、↑のSELECTはキャッシュが効かないときはどのくらいかかっ ているかわかりますか？もし、 1. ↑のSELECTの実行開始 2. 更新処理開始（1.は実行中） 3. 更新処理終了（1.は実行中） 4. 1.の途中でクラッシュ という流れが起こり得るならそれが関係しているかもしれません。 > - 昨年12月頃から発生?(6.1.1/6.11に上げてからか、その時期に行ったSQL修正等が原因かは不明) このバージョンのときは確実に大丈夫だった、というバージョンっ てわかりますか？わかればそこからの差分を確認できるのです。 > - クラッシュした後 mroonga_operationsに type:update のレコードが残っているケースが多いです(100%ではありません)。 ということなので、↑のSELECT実行中に更新処理が完了というパター ンがありそうな気がするんですよねぇ。 > 何か必要な情報、或いは情報取得のための手段がありましたらお申し付けください。 Groongaにパッチを当てて動かしてその結果を教えてもらうという のはアリですか？こんなチェックを入れると直るかというのを試し たいのですが。。。 https://github.com/groonga/groonga/commit/d0106b41c418ddd8354092850ac6cc012a0bd4af.patch もし、RPMになっていたら試せるということであればRPMを作ります。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート： http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス： http://www.clear-code.com/recruitment/ OSS開発支援サービス: http://www.clear-code.com/blog/2016/6/27.html
