yoku ts.
yoku0****@gmail*****
2015年 7月 17日 (金) 12:07:59 JST
こんにちはyoku0825です。 > 再現性微妙なんですよねぇ。。 > （同じクエリーでも再度実行すると通る。 > けど、mroonga_lock_timeoutを短めにするとたぶんまた出る） > > 幾分前になってしまってバイナリーログが遠いところに行っているので、 > mroonga_lock_timeout短めにして前後のバイナリーログ取りたいと思います。 あれ以来mroonga_lock_timeout= 1000で動かしていてクエリーは変わってないんですが出なくなりました。。 お騒がせしました(´･ω･｀) yoku0825 2015年7月6日 10:05 yoku ts. <yoku0****@gmail*****>: > 件名変えました。 > > >>> そういえば、このワーニングって何かよくない影響あったりしますか？ >> >> 単に無視するだけなので、よくない影響はないはずです。 > > むーん、そうなのですか。 > じゃあたまたまなのかなぁ。。 > > >> うーん、groonga.logにバックトレースがでていると思うのでそれ >> を見せてもらえませんか？どこの処理でロックが競合しているかが >> わかるかもしれません。 > > https://gist.github.com/yoku0825/a35a9ba9c619a8ebbad2 > > バックトレースはこんな感じでした。 > フツーに(?)刺さった時と同じでgrn_ii_column_updateの中で失敗しています。 > > 再現性微妙なんですよねぇ。。 > （同じクエリーでも再度実行すると通る。 > けど、mroonga_lock_timeoutを短めにするとたぶんまた出る） > > 幾分前になってしまってバイナリーログが遠いところに行っているので、 > mroonga_lock_timeout短めにして前後のバイナリーログ取りたいと思います。 > > 取り急ぎ返信まで。 > > > yoku0825, > > 2015年7月3日 21:52 Kouhei Sutou <kou****@clear*****>: >> 須藤です。 >> >> 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/ >> >> _______________________________________________ >> groonga-dev mailing list >> groon****@lists***** >> http://lists.osdn.me/mailman/listinfo/groonga-dev
