[groonga-dev,03652] Re: Mroonga_で_data_truncated_for_primary_key_column: <id> が発生する(解決)

Back to archive index

各務 洋 kagam****@outwa*****
2015年 11月 11日 (水) 18:15:44 JST


お世話になります、各務です。

> 私がやっていたAuto repair対応はクラッシュするとき用のもので
> あり、クラッシュしないときは何も影響がありません。

ありがとうございます。
Mroonga 5.04 を 再起動した際のクラッシュ時に破損はありました。
(≧▽≦;)
ただこの時はテーブル破損が先だったかが分からないので。。。

何が言いたいかと言いますと、次に yum update する時 に FLUSH TABLES; 
するという事しか頭になくて、再起動する際の事を失念していました〜。
という情報共有まで。


> (あったらバグです。ただ、性能が落ちるのはしょうがないです。
> 余計なことをしているので。。。できるだけ落ちないようにはして
> いますが。。。)

えーと、auto repair でご報告があるのですが、別タイトルで報告しな
おしたいと思います。


> なので、私がやっているやつをいくら進めても各務さんの本番環境
> での問題は解決しないのです。(検証環境での問題は解決するかも
> しれません。)

snip

> 
> これ(問題2のこと)は矢田さんが直してくれたやつで直っている
> はずです。(検証環境でクラッシュさせながら検証しても直ったか
> どうかは確認できないので注意してください。)

了解です。実は……そうかもなぁと思っていたのです。
その上でダメだった際に次のトラップがあると良いと思ったので、auto 
repair も心強くなれると思うのです。

ですので、このタイトルは一旦解決にして様子を見たいと思うのですが、
いかがでしょうか?


> もし直っていなかったらUNIQUE INDEXを作成するときにUSING HASH
> を指定しても発生するか確認してもらえますか?これで発生しなく
> なるなら、パトリシアトライの実装に矢田さんが直したもの以外の

ぉお!?……USING HASH が使える(機能もさることながら速度的にも)
のですか!?!?
Unique Index 側は範囲検索しない完全一致の使い方をしていますので、回避
(暫定的にせよ)では全然有りなのです!!!
(日付は範囲検索ですけど)

で改めて今更で申し訳ないのですが、整数値や日付も btree ではなくパトリ
シアトライを……、あ、書いてありました。

http://redmine.groonga.org/projects/mroonga/wiki/%E5%88%A9%E7%94%A8%E8%80%85%E5%90%91%E3%81%91_FAQ

ちなみに数値にパトリシアトライを使うメリットというのはどういう事がある
のかよければ知りたいです。


> バグがまだあります。
……頑張って確認してみまーす(としか言いようがないのです……)


> 問題1の方は、次に再現したときに、
> 
>   * タイムスタンプ入りのクエリーログ
>     (手順は覚えていないんですが、MySQLで取得できた気がします)

SET GLOBAL general_log = 'ON';
ですよね?
UPDATE 文の実行時でよければ取得可能だと思います。



----
各務
kagam****@outwa*****




groonga-dev メーリングリストの案内
Back to archive index