Susumu Yata
yata****@razil*****
2015年 12月 15日 (火) 20:18:55 JST
矢田です． 先ほどの説明に不足がありましたので，補足いたします． 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*****>
