Kouhei Sutou
kou****@clear*****
2015年 7月 3日 (金) 21:52:38 JST
須藤です。 In <CAHB5oTNVU0X=Bxcqe884Mc8Ky5-_mo-ag+92OooueS=oxHaR****@mail*****> "[groonga-dev,03328] Re: Mroonga 5.03 ストレージモードで MySQL 5.6 のレプリケーションが切断される" on Wed, 1 Jul 2015 16:35:54 +0900, "yoku ts." <yoku0****@gmail*****> wrote: > UPDATEで強制的に全カラムをSET句に詰め込まれるO/Rマッパーを > 使っている現場で働いているyoku0825です。 おぉ。。。 >> UPDATEのSETにプライマリー >> キーを指定しているわけ、ではないですよねぇ、さすがに。 > > そういえば、このワーニングって何かよくない影響あったりしますか？ 単に無視するだけなので、よくない影響はないはずです。 GRN_TABLE_DAT_KEYを使ったテーブルを作れるようにすると、プラ イマリーキーの変更もサポートできるんですが、プライマリーキー を変えたいケースがあるような気がしないので↑という挙動になっ ています。 > ``` > mysql> INSERT INTO t1 VALUES (1, 'one'); > Query OK, 1 row affected (0.00 sec) > > mysql> UPDATE t1 SET num = 1, val = 'one' WHERE num = 1; > Query OK, 1 row affected, 1 warning (0.00 sec) > Rows matched: 1 Changed: 1 Warnings: 1 > > mysql> UPDATE t1 SET num = 1, val = 'two' WHERE num = 1; > Query OK, 1 row affected, 1 warning (0.00 sec) > Rows matched: 1 Changed: 1 Warnings: 1 > ``` > > というようなクエリーをマスターから投げると、レプリケーションスレーブの方で、 > SQLスレッドしかテーブルを更新するやつはいないはずなのに > 次のステートメントがgrn_io_lock_failedで転ける(3000msでタイムアウトする)という > 再現性が微妙な現象が発生していたのを思い出しました。 > > START SLAVE sql_threadでそのまま起動できたので、ロックが突き刺さってるわけじゃなくて > ロックの開放が何故か遅延しているような感じだったんですが。。 > > 何かよくない影響があれば教えてください :( うーん、groonga.logにバックトレースがでていると思うのでそれ を見せてもらえませんか？どこの処理でロックが競合しているかが わかるかもしれません。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート: http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス: http://www.clear-code.com/recruitment/
