Kouhei Sutou
kou****@clear*****
2015年 10月 7日 (水) 19:17:01 JST
須藤です。 In <20151****@domai*****> "[groonga-dev,03550] Re: Mroonga で data truncated for primary key column: <id> が発生する" on Mon, 05 Oct 2015 20:40:32 +0900, 各務 洋 <kagam****@outwa*****> wrote: >> 実は、該当レコードのタイムスタンプと問題発生時間の相関はない >> のです。このテーブルは木構造のデータ構造でレコードを管理して >> いるのですが、該当レコードが2つ見えているということは、その >> 木構造の中のノードのリンクが壊れているということです。該当レ >> コードではなく、ノードのリンクが壊れていることがポイントです。 > > なるほど、この時の INSERT とは限らないという事ですね。 はい、その通りです。 > 同じく、同一キーでの削除と追加時に発生すると考えています。 > （本番環境でもこれが多いので） 同一キーかどうかは発生しやすしさに影響がある気はします。 ただ、削除と追加時はノードのリンクを変更しているので、発生す る可能性は十分あります。 > lock_clear を行わない状態でテストしてみました。 > （ちょっとパターン変えました） ありがとうございます！ > 0 での重複しか再現できませんでしたが、Duplicate Index 状態にはなりました。 > >> select --table tbl_test_pat_0005 > [[0,1444042564.47682,0.042431116104126],[[[2],[["_id","UInt32"],["_key","Int64"],["a_id","Int64"],["id","Int64"],["t1_date","Time"],["t2_date","Time"],["t_text","LongText"]],[248,964278,0,0,0.0,0.0,""],[248,964278,0,0,0.0,0.0,""]]]] え、あれ。。。重複したレコードがでていますね。。。 このテーブルは一度問題が発生したテーブルをそのまま使ったもの ですか？それとも作りなおしたものですか？ 一度問題が発生したならすでに壊れていてこうなることはありそう ですが、作りなおしてしかもlock_clearを使っていないでこれにな るなら、だいぶおかしいですね。。。 >> select --table tbl_test_pat_0005 --query a_id:10001 > [[0,1444042653.16585,0.00229477882385254],[[[1],[["_id","UInt32"],["_key","Int64"],["a_id","Int64"],["id","Int64"],["t1_date","Time"],["t2_date","Time"],["t_text","LongText"]],[183,964507,10001,964507,1444028598.0,0.0,"t10001"]]]] > > ↑これも全件表示では出てこないが、指定すると出てきました。 > （Mroonga からも同一ですね。） テーブルをトラバースするとでてこなくて、直接IDを指定すると （インデックスで見つけたときは直接IDを指定してレコードをとり だします）でてくるということですね。完全に壊れていますね。。。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート: http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス: http://www.clear-code.com/recruitment/ コードリーダー育成支援 - 自然とリーダブルコードを書くチームへ: http://www.clear-code.com/services/code-reader/
