Susumu Yata
yata****@razil*****
2015年 12月 16日 (水) 17:49:38 JST
矢田です． 須藤さんと森さんにも相談してみた結果， 別プロセスで truncate されたときは， 即時 database_unmap すべきという結論に至りました． しかし，常時 select をかけているような使い方であれば， 即時というのは無理があるため，仰られているように， database_unmap してキャッシュをクリアするしかなさそうです． 今のところ，別プロセスで truncate されたことを検出して select をエラーにすることはできそうなのですが， エラーにはしない方がハッピーでしょうか？ エラーにすることで不幸が訪れるようであれば， 警告レベルでログを出すくらいに留めようかと思っています． 2015年12月16日 14:01 Yutaro Shimamura <yu****@irx*****>: > > 矢田さん > > ひとまず今はtruncateした後にクエリキャッシュを0にして戻すのが確実そうですね。 > 僕の使ってる環境がselectが常にかかってる状態なのでそっちを止めるのが難しそうだったので‥ > > MySQLだとtruncate時にクエリキャッシュを全部flushしてるみたいなので、groongaもクエリキャッシュをflushするコマンドがあればいいのかな‥ > > 調査ありがとうございました！教えてもらった手順で回避してみます。 > > 2015-12-15 12:18 GMT+01:00 Susumu Yata <yata****@razil*****>: >> >> 矢田です． >> >> 先ほどの説明に不足がありましたので，補足いたします． >> >> Proc. 1 で truncate した後， Proc. 2 で database_unmap する前に >> select してしまうと古いデータを参照したクエリキャッシュが残ります． >> Proc. 1 で truncate した後， Proc. 2 ですかさず database_unmap できれば， >> 明示的にクエリキャッシュをクリアする必要はありません． >> >> よろしくお願いします． >> >> 2015年12月15日 20:08 Susumu Yata <yata****@razil*****>: >> > 矢田です． >> > >> > database_unmap をしても古いレコードが見える現象については， >> > クエリキャッシュが原因と判明しました． >> > 一度クエリキャッシュを無効にすることで， >> > truncate が反映された結果を得ることができます． >> > >> > 以下，説明になります． >> > >> > （前半省略） >> >> database_unmap >> > [[0,1450176830.60625,0.000785589218139648],true] >> >> select tbla >> > >> > [[0,1450176832.73568,7.08103179931641e-05],[[[1],[["_id","UInt32"],["_key","ShortText"],["cola","ShortText"]],[1,"kv1","stc1"]]]] >> > >> > database_unmap を実行した時点でテーブルは閉じられるのですが， >> > "select tbla" がクエリキャッシュに残っているために， >> > 古い検索結果がそのまま使われてしまっています． >> > このことは，条件の異なる select を実行してみると分かります． >> > >> >> select tbla --limit 5 >> > >> > [[0,1450177316.72481,0.000406503677368164],[[[0],[["_id","UInt32"],["_key","ShortText"],["cola","ShortText"]]]]] >> > >> > 行き当たりばったりな対応ではありますが， >> > クエリキャッシュを捨てていただければ， >> > 同じ条件でも truncate が反映された結果が得られます． >> > >> >> cache_limit 0 >> > [[0,1450176835.51223,5.65052032470703e-05],100] >> >> select tbla >> > >> > [[0,1450176837.88635,0.000384807586669922],[[[0],[["_id","UInt32"],["_key","ShortText"],["cola","ShortText"]]]]] >> > >> > このままではクエリキャッシュが無効になってしまうので， >> > あらためて有効にする必要があります． >> > >> >> cache_limit 100 >> > [[0,1450177190.31331,5.10215759277344e-05],0] >> > >> > truncate を自動で検出して開き直すことができないか検討しているのですが， >> > 自動検出まではできても安全に開き直すことは難しそうで，難航しています． >> > >> > 以上です． >> > >> > 2015年12月14日 11:40 Susumu Yata <yata****@razil*****>: >> >> 矢田です． >> >> >> >> 私の環境でも同様の問題が起きることを確認いたしました． >> >> また， TABLE_HASH_KEY, TABLE_PAT_KEY では再現しますが， >> >> TABLE_DAT_KEY では再現しませんでした． >> >> >> >> このことから， grn_hash, grn_pat では truncate を別プロセスで >> >> 検出できていないのではないかと思います． >> >> >> >> 調査してみます． >> >> >> >> 2015年12月13日 21:39 Yutaro SHIMAMURA <yu****@irx*****>: >> >>> >> >>> お久しぶりです！ >> >>> >> >>> ある一つのDBを複数のプロセスで使用している時、 >> >>> どれか一つのプロセスからtruncateを実行しても他のプロセスから見るとレコードが残り続けるという現象にぶつかりました。 >> >>> >> >>> * プロセス1 >> >>>> table_create tbla TABLE_HASH_KEY ShortText >> >>> [[0,1450009296.21617,0.0567305088043213],true] >> >>>> column_create tbla cola COLUMN_SCALAR ShortText >> >>> [[0,1450009297.84113,0.048534631729126],true] >> >>>> load --table tbla --values [{\"_key\":\"kv1\",\"cola\":\"stc1\"}] >> >>> [[0,1450009387.73932,0.000219821929931641],1] >> >>>> select tbla >> >>> >> >>> [[0,1450009393.44995,0.000159502029418945],[[[1],[["_id","UInt32"],["_key","ShortText"],["cola","ShortText"]],[1,"kv1","stc1"]]]] >> >>> >> >>> >> >>> * この状態でプロセス2を起動 >> >>>> select tbla >> >>> >> >>> [[0,1450009397.69844,0.000183820724487305],[[[1],[["_id","UInt32"],["_key","ShortText"],["cola","ShortText"]],[1,"kv1","stc1"]]]] >> >>> >> >>> >> >>> * プロセス1でtruncate >> >>>> truncate tbla >> >>> [[0,1450009402.65819,0.112846612930298],true] >> >>>> select tbla >> >>> >> >>> [[0,1450009413.23927,7.53402709960938e-05],[[[0],[["_id","UInt32"],["_key","ShortText"],["cola","ShortText"]]]]] >> >>> ↑消えてる >> >>> >> >>> * プロセス2でselect, unmapやio_flushしてみる >> >>>> select tbla >> >>> >> >>> [[0,1450009418.21568,7.84397125244141e-05],[[[1],[["_id","UInt32"],["_key","ShortText"],["cola","ShortText"]],[1,"kv1","stc1"]]]] >> >>> ↑残ってる >> >>>> database_unmap >> >>> [[0,1450009429.77373,0.00843930244445801],true] >> >>>> select tbla >> >>> >> >>> [[0,1450009433.26145,5.17368316650391e-05],[[[1],[["_id","UInt32"],["_key","ShortText"],["cola","ShortText"]],[1,"kv1","stc1"]]]] >> >>>> io_flush >> >>> [[0,1450009599.38242,0.0351345539093018],true] >> >>>> select tbla >> >>> >> >>> [[0,1450009602.99016,5.07831573486328e-05],[[[1],[["_id","UInt32"],["_key","ShortText"],["cola","ShortText"]],[1,"kv1","stc1"]]]] >> >>> ↑まだいる >> >>> >> >>> * プロセス2を抜けてもう一度起こす >> >>>> quit >> >>> # groonga test.grn >> >>>> select tbla >> >>> >> >>> [[0,1450009738.21378,0.000265359878540039],[[[0],[["_id","UInt32"],["_key","ShortText"],["cola","ShortText"]]]]] >> >>> ↑いなくなる >> >>> >> >>> >> >>> 既知の問題で報告かぶってたらすいません！ >> >>> よろしくお願いします。 >> >>> _______________________________________________ >> >>> groonga-dev mailing list >> >>> groon****@lists***** >> >>> http://lists.osdn.me/mailman/listinfo/groonga-dev >> >> >> >> >> >> >> >> -- >> >> Susumu Yata <yata****@razil*****> >> > >> > >> > >> > -- >> > Susumu Yata <yata****@razil*****> >> >> >> >> -- >> Susumu Yata <yata****@razil*****> >> _______________________________________________ >> groonga-dev mailing list >> groon****@lists***** >> http://lists.osdn.me/mailman/listinfo/groonga-dev > > > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.osdn.me/mailman/listinfo/groonga-dev > -- Susumu Yata <yata****@razil*****>
