Kouhei Sutou
kou****@clear*****
2015年 10月 28日 (水) 15:53:38 JST
須藤です。 In <20151****@domai*****> "[groonga-dev,03599] Re: Mroonga_で_data_truncated_for_primary_key_column: <id> が発生する" on Tue, 27 Oct 2015 11:30:49 +0900, 各務 洋 <kagam****@outwa*****> wrote: > ありがとうございます、groonga.log に Auto repair is done が出てきました！ よかったです！ > 但し、課題があると思うのです。 > > Index の再構築の間、Unique が剥がされている間に、複数の重複登録が行え > ているようです。 > > その後、Auto repair is done と出る頃には重複済のテーブルに Unique 属性 > が戻っているように見えるのですが、以降のテーブルに Unique が一切効かな > い状態になっています。 おぉ。。。 テーブルのオープンはマルチスレッドで動くんですか。。。 auto repair中はロックをとってスレッドでマルチスレッドでも同 時に処理しないようにしました。 http://packages.groonga.org/tmp/mysql-community-mroonga-5.09-2.el6.x86_64.rpm 頻繁に接続・切断を繰り返しているケースでは多少影響があると思 いますが、多くの場合はそんなことをしていないと思うので性能へ の影響は軽微じゃないかと思っています。 > 処理中はテーブルロック（他からは READ 可能な方が良い気がします）がある > と良いのかなぁと思いましたが、どうでしょうか？ これ、auto repair発動中はINSERTをブロックするということです よね？そうすると性能に影響がある気がするので、違うところでロッ クをかけるようにしました。 ロックが正常に機能するためには関連する処理全部がロックを意識 しなければいけません。INSERTでブロックをするということは INSERTする前は（auto repairが関係ないときでも）常にロックが かかっていないことを確認する必要があります。これが性能に影響 しそうだなぁと思ったのです。 > また検知の開始時期は分からないのですが、 クラッシュ後、最初にテーブルを開いたとき（最初にテーブルに触っ たとき）に動くようになっています。 そのタイミングでロックをかけています。 同じ接続中になんどもINSERTする場合でもテーブルは1度しか開き ません。そのため、トータルでのオーバーヘッドはこっちの方が小 さくなりそうなのでそうしました。 > 2015-10-27 10:58:13.401678|n|a00b9700|DDL:obj_remove tbl_test_pat_0005-a_id > 2015-10-27 10:58:13.417480|n|a00b9700|DDL:obj_remove tbl_test_pat_0005-a_id.index > > と、時間に差があるのも気になる点ではあります。 これはしょうがないのです。。。 テーブル削除はファイルを削除するためI/Oが走ります。そのため、 メモリー上で終わる処理に比べて時間がかかるのです。。。 -- 須藤 功平 <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/
