Kouhei Sutou
kou****@clear*****
2015年 11月 10日 (火) 22:53:01 JST
須藤です。 回答ありがとうございます。 In <20151****@domai*****> "[groonga-dev,03642] Re: Mroonga_で_data_truncated_for_primary_key_column: <id> が発生する" on Tue, 10 Nov 2015 13:07:39 +0900, 各務 洋 <kagam****@outwa*****> wrote: >> 以下についてyes/noを教えてもらえますか？ >> （私はぜんぶyesだと認識していました。） >> >> * 問題1 >> * 現象：UPDATE 文発行時に warning で data truncated for primary >> key column: <id> が発生 >> * →yes/no > + yes > >> * mysqldのクラッシュの有無：無 >> * →yes/no > + 検証環境では、クラッシュ有、本番環境では クラッシュ無 > >> * 発生を確認した一番新しいGroongaのバージョン：5.0.7-1.el6 >> * →yes/no > + yes > >> >> * 問題2 >> * 現象：unique 制約のある a_id に 0 が入る、または、 >> 10001 が無くてもduplicate insert が発生 >> * →yes/no > + yes > >> * mysqldのクラッシュの有無：無 >> * →yes/no > + 検証環境では、クラッシュ（執拗な kill）有、本番環境では クラッシュ無 > >> * 発生を確認した一番新しいGroongaのバージョン：5.0.7-1.el6 >> * →yes/no > + no, 10/22 groonga-libs-5.0.9-1.el6 でも発生。 この発生したのは検証環境であって本番環境ではないですよね？ その前提で話をすると。。。 私がやっていたAuto repair対応はクラッシュするとき用のもので あり、クラッシュしないときは何も影響がありません。 （あったらバグです。ただ、性能が落ちるのはしょうがないです。 余計なことをしているので。。。できるだけ落ちないようにはして いますが。。。） なので、私がやっているやつをいくら進めても各務さんの本番環境 での問題は解決しないのです。（検証環境での問題は解決するかも しれません。） > この本番環境では mysqld のクラッシュとは関係無く……。 > おっと、「a_id に 0 が入った」時だけはクラッシュ時でした。これは本番環 > 境では稀なのと、手動で kill した時でしたので気にしていませんでした。 はい、気にしないで大丈夫です。 > P.S > index の破損は、DELETE 時に起きていて、INSERT 等の index 更新とかち合 > うタイミングで発生していると思うのです。 これ（問題2のこと）は矢田さんが直してくれたやつで直っている はずです。（検証環境でクラッシュさせながら検証しても直ったか どうかは確認できないので注意してください。） もし直っていなかったらUNIQUE INDEXを作成するときにUSING HASH を指定しても発生するか確認してもらえますか？これで発生しなく なるなら、パトリシアトライの実装に矢田さんが直したもの以外の バグがまだあります。 問題1の方は、次に再現したときに、 * タイムスタンプ入りのクエリーログ （手順は覚えていないんですが、MySQLで取得できた気がします） * groonga.log（ログレベルなど設定はデフォルトでよいです） を取得して提供してもらえないでしょうか？それらがあり、それら をタイムスタンプを付きあわせて確認すると原因を予想できる気が しています。 -- 須藤 功平 <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/
