[groonga-dev,01671] Re: mroonga適用テーブルへの「WHERE IN 多数」クエリでエラー

Back to archive index

Kouhei Sutou kou****@clear*****
2013年 8月 23日 (金) 17:03:02 JST


須藤です。

In <BAY17****@phx*****>
  "[groonga-dev,01657] Re: mroonga適用テーブルへの「WHERE IN 多数」クエリでエラー" on Wed, 21 Aug 2013 19:35:19 +0900,
  K A <a_kira1****@hotma*****> wrote:

> また、文面に不明確な部分がありお手数おかけしてすみません。

いえいえ!

>> 「エラーが再発」というのは「WHERE IN 多数」クエリが遅くなる
>> ということであっていますか?
> 
> 遅くなるのではなく、
> 「ERROR 1030 (HY000): Got error 1 from storage engine」
> と出て結果が返ってこないという状況です。
> 
> 結果が正常に返る場合には、速度的にも0.00〜0.01secと問題はないんですが、失敗する場合は必ず上記のエラーになっています。
> 「時間がかかって成功」というケースは見かけません。
> 
> 
>> また、「cronによる自動更新処理」と「cronによる処理」は同じものですか?
>> 違うものですか?
> 
> 表現が不統一ですみません。
> この2つは同じものです。

確認ありがとうございます!
わかりました。

> すると、一体いつ、どんな処理がデータベースに混乱をもたらしているのか?
> というのが現在の疑問です。

そうですねぇ。

>> もし、同一サーバーに余裕があるのであれば、同一サーバー上で検
>> 証できると思います。理由は、データベース作成直後は正常→1日放
>> 置で再現、というように再現できているからです。
> 
> いただいたヒントから考えると、
> 
> 1. インポートなりインデックスの張り直しなりで正常に動くDBを確保
> 2. そのDBをプロジェクトの主DBとして1日放置。その間、実行されるすべてのクエリをロギング
> 3. 同時に、cronから「WHERE IN 多数」クエリを毎分実行し、その都度成否を保存する
> 
> といったアプローチが妥当でしょうか。
> そして「WHERE IN 多数」クエリのエラーを確認でき次第、直前に走っていた更新クエリをリストアップして、インポート直後の正常なDBに対して順次実行してみる、という手順でしょうかね・・・。

はい、そうです。
地道ですが。。。

> あまりにも難航しているので、いっそ全部壊して作り直したいような気持ちになりかけてますが、それで再発したら本当に目も当てられないのでもう少し粘ってみます。
> どうもありがとうございますm(_ _)m

おぉ、あまりムリしないでください。。。
うまく原因がわかるといいのですが。。。

-- 
須藤 功平 <kou****@clear*****>
株式会社クリアコード <http://www.clear-code.com/> (03-6231-7270)

groongaサポート:
  http://groonga.org/ja/support/
パッチ採用はじめました:
  http://www.clear-code.com/recruitment/
コミットへのコメントサービスはじめました:
  http://www.clear-code.com/services/commit-comment.html




groonga-dev メーリングリストの案内
Back to archive index