Kouhei Sutou
kou****@clear*****
2015年 10月 28日 (水) 19:53:49 JST
須藤です。 In <20151****@domai*****> "[groonga-dev,03602] Re: Mroonga_で_data_truncated_for_primary_key_column: <id> が発生する" on Wed, 28 Oct 2015 18:28:22 +0900, 各務 洋 <kagam****@outwa*****> wrote: >> 頻繁に接続・切断を繰り返しているケースでは多少影響があると思 >> いますが、多くの場合はそんなことをしていないと思うので性能へ >> の影響は軽微じゃないかと思っています。 > > 私の環境では Web で使用しているので、接続・切断は頻繁で、接続したまま > の方が少ないのです。 おぉ。。。 ちなみに、1接続1SELECTとか1接続1INSERTみたいな感じですか？ 同時接続数が少なければ影響は少ないと思いますが。。。 >> これ、auto repair発動中はINSERTをブロックするということです >> よね？ > > はい。イメージとしては、innodb の reindex や ALTER TABLE 〜 ENGINE の > 時の挙動です。 > この修復が終わるまで影響のある他の処理は全部順番待ちね〜といった所です。 > innodb も SELECT まで待たせることもあるので、ガッチリロックもありだと > 考えた次第です。 なるほど。 > 気になる点はお送りしたログ上の > >> 2015-10-27 10:54:56.879764|n|cda62720|log level is 'DUMP' >> 2015-10-27 10:58:13.401678|n|a00b9700|DDL:obj_remove tbl_test_pat_0005-a_id > > こちらの3分少々の差の方なのです。（分かりにくくて申し訳ありません） なんと。。。 > テスト上、 mysqld が上がってくるとほぼ同時にテーブルを触っているので。 > （処理は動かしっぱなしなのです） > > この3分少々は想定内でしょうか？なおレコードは最大でも55,000件以内です。 これは想定外で、たぶん、このときは誤検出しています。 クラッシュで残ってしまった操作ログではなく、書き込み中の操作 ログを見てauto repairを発動してしまっています。 最初にデータベースを開いたとき（= クラッシュ後最初にアクセス されたとき）だけ、操作ログが残っているかをチェックするべきで す。で、このケースはそのように直したので、最新のやつだと直っ ているはずです！ -- 須藤 功平 <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/
