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

Back to archive index

K A a_kira1****@hotma*****
2013年 8月 21日 (水) 19:35:19 JST


木村です。須藤さんお忙しい中ご回答ありがとうございます。
また、文面に不明確な部分がありお手数おかけしてすみません。


> 「エラーが再発」というのは「WHERE IN 多数」クエリが遅くなる
> ということであっていますか?

遅くなるのではなく、
「ERROR 1030 (HY000): Got error 1 from storage engine」
と出て結果が返ってこないという状況です。

結果が正常に返る場合には、速度的にも0.00〜0.01secと問題はないんですが、失敗する場合は必ず上記のエラーになっています。
「時間がかかって成功」というケースは見かけません。


> また、「cronによる自動更新処理」と「cronによる処理」は同じものですか?
> 違うものですか?

表現が不統一ですみません。
この2つは同じものです。

cronでは
・AutoMySQLBackupによるmysqldumpと、
・CakePHPで自作したDailyシェル
の2つが走っています。

AutoMySQLBackupは広く普及しているスクリプトの上、データの読み出ししかしていないと思うので、容疑者(?)からは除外しています。

DailyシェルはWeb上からデータを拾ってきて解析し、整理してDBに格納するものです。
更新系クエリを多数含みますが、SELECTクエリも多く、その中には数件の「WHERE IN 多数」タイプが含まれます。


ログによれば、エラーが再発しているのは後者のDailyシェルの実行中でした。
なので最初はDailyシェル内の更新系クエリの影響を疑ったんですが、

1. 新DBを作成し、旧DBからデータをインポートして正常動作を確認
2. 手動でDailyシェルを走らせて新DBを更新
3. 更新された新DBに対して「WHERE IN 多数」クエリを実行

というテストを行っても、上記エラーが再現しないわけです。

なので、
「原因はDailyシェル内の更新クエリにあるわけではなく、Dailyシェル内で実行されている『WHERE IN 多数』クエリによってたまたまトラブルが露呈しただけ」
だと判断しました(※厳密にいえば、Web上から拾ってきたデータの内容や量によってDailyシェルの処理内容自体も多少変わるので、これも確定とはいえないんですが)。

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


> もし、同一サーバーに余裕があるのであれば、同一サーバー上で検
> 証できると思います。理由は、データベース作成直後は正常→1日放
> 置で再現、というように再現できているからです。

いただいたヒントから考えると、

1. インポートなりインデックスの張り直しなりで正常に動くDBを確保
2. そのDBをプロジェクトの主DBとして1日放置。その間、実行されるすべてのクエリをロギング
3. 同時に、cronから「WHERE IN 多数」クエリを毎分実行し、その都度成否を保存する

といったアプローチが妥当でしょうか。
そして「WHERE IN 多数」クエリのエラーを確認でき次第、直前に走っていた更新クエリをリストアップして、インポート直後の正常なDBに対して順次実行してみる、という手順でしょうかね・・・。


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



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