[groonga-dev,02225] Re: MroongaストレージモードでINSERT, DELETEが競合してクラッシュ

Back to archive index

Kouhei Sutou kou****@clear*****
2014年 4月 16日 (水) 11:07:52 JST


須藤です。

In <CAHB5oTNbWGK7j4A_LyZ16js4Rjp1uLe0wqC9VF8eCkHRGjt1_g****@mail*****>
  "[groonga-dev,02224] Re: MroongaストレージモードでINSERT, DELETEが競合してクラッシュ" on Wed, 16 Apr 2014 10:14:21 +0900,
  "yoku ts." <yoku0****@gmail*****> wrote:

>> DELETE FROM tableがきたらTRUNCATE TABLE tableと同じ処理をする
>> ようにしていたんですが、TRUNCATEは速い代わりに他のコネクショ
>> ンがつないでいるときに実行してしまうとクラッシュするので、1
>> 件ずつ削除するようにしました。
> 
> 先生、その(delete_all_rowsをstorage_truncateに送る)動作よりも、
> storage_truncate(からgrn_table_truncate)の動作で落ちないようになると嬉しいです!
> 
> 内部的に削除, 再作成になるので、grn_io_lockは使えないという感じでしょうか。
> mysql_lock_tablesをstorage_truncateのアタマあたりに入れられたりすると良いような気がするのですが。。
> 
> ご一考ください。

一考しました!
mysql_lock_tables()だとムリですねぇ。。。

ロックして他のINSERTの処理とかを同時に動かないようにしても、
storage_truncate()した後は他の全部のコネクションで該当テーブ
ルをオープンし直さないといけないんです。作りなおしているので、
古い削除済みのテーブルをオープンしたままだとクラッシュするん
です。古いテーブルのリソースはすでに開放されているので。

mysql_lock_tables()方向で行くなら「他のコネクション全部でテー
ブル再オープンする」という処理も入れなきゃいけないんですが、
この追加の処理をやるのって現実的じゃないんですよ。。。全部の
コネクションをMroongaが管理しているか、各コネクションが
TRUNCATEされたかどうかを逐一チェックするみたいなことをしなけ
ればいけないので。


ということを考えると、そもそもTRUNCATEする前はLOCK TABLESし
てねっていうは作業が不足していますね。他に接続がない状態で
TRUNCATEしてね、ということになります。

TRUNCATEのドキュメントをみると他のストレージエンジンでもテー
ブルをドロップしてから再作成しているみたいなんで、Mroongaに
限らず同じ処理の流れなんですかねぇ。

  http://dev.mysql.com/doc/refman/5.1/ja/truncate.html

  切り捨て操作は、テーブルをドロップ、再作成します。


-- 
須藤 功平 <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/code-reader/




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