Kouhei Sutou
kou****@clear*****
2015年 10月 5日 (月) 16:57:25 JST
須藤です。 In <20151****@domai*****> "[groonga-dev,03547] Re: Mroonga で data truncated for primary key column: <id> が発生する" on Mon, 05 Oct 2015 12:46:33 +0900, 各務 洋 <kagam****@outwa*****> wrote: >> 各務さん、これ（Groongaでselectすると同じ_idのレコードが返っ >> てくる）が発生したときにlock_clearは使っていましたか？ >> 使っていたら発生してもおかしくないんですが、使っていなかった >> ら発生するのはおかしいんです。 > > ご返答ありがとうございます。テスト時のログを確認してみました。 ありがとうございます！ > lock_clear はこの現象の後に使うように追加しているので、まだ使っていな > い可能性が高いと思うのです。 > > （レコードの timestamp が 16:29 で、16:49 に mysqld の自動再起動に > 1分20秒掛かって、ここで追加しています） 実は、該当レコードのタイムスタンプと問題発生時間の相関はない のです。このテーブルは木構造のデータ構造でレコードを管理して いるのですが、該当レコードが2つ見えているということは、その 木構造の中のノードのリンクが壊れているということです。該当レ コードではなく、ノードのリンクが壊れていることがポイントです。 リンクはレコードの追加・削除のとき（!= 該当レコード作成時） に変更するので、そのときに正しく変更できなければ壊れるのです。 ということで、lock_clearが原因で壊れた可能性が高いと思いまし た。 > とはいえ、すっきりしないので、再度試してみたいと思います！ > （ただ、0 ではない重複はなかなか再現しないのです……。） ありがとうございます！ が、現時点での情報でかなり怪しいのでムリしなくて大丈夫です！ > ちなみに、これは Mroonga のログに何か出たりするものでしょうか？ > mroonga_log_level = DUMP にしているのですが、特に変わらないようですので。 > 2015-09-30 16:31:03.147158|d|ba32a700|failed to find d=2 > ↑というのは出てきていました。 すみません、なにも出力するようにしていないので、DUMPでも出力 されないのです。 > P.S > そういえば、 Index 上は a_id は 10001 で入っているようでした。 インデックスはレコードを保存している木構造データとは別の木構 造データなんですが、こっちは壊れていないということだと思いま す。（10001というのがあるのでMroongaレベルでは壊れているので すが、Groongaレベルでは壊れていないという意味。） -- 須藤 功平 <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/
